A Pivot

Funny sometimes how something sticks in your mind. When you mention Pivot all I can see is "Ross" in friends manfully trying to direct Chandler and Rachel to move a sofa up a set of winding stairs. You sat there watching knowing they were really going to struggle.

A Pivot though isn't just about a sofa and a set of stairs, it's an equally challenging approach to helping an organisation move from being solution focused to clients to being more product oriented. The reason for a Technology Pivot usually stems from a need to adjust how a business works, improve productivity, alleviate constraints in development or operations (but likely in both), break down elements of legacy or debt and to create more specialists in your software.

As a Transformation leader you will quickly assess what they do today, map out the constraints/blockers to a good flow of work and look at the technology inhibitors so that you can design what the target looks like. Simple, should have that done in a month or two !

The challenge always comes in how something is effected, I'm always guided by the old quote that no plan survives first contact. If a consultant is needed it's most likely due to the organisation not having the time, the skills or both to make the change that is needed. Lets face it is it was simple it would already have been done and a Pivot isn't easy.

What I like about the Pivot is the move away from cross cutting developers that develop code across the entire software landscape. I've seen (and is well accepted) that specialists in the code base take pride in the bit they own and want to ensure it's of the highest quality and has the lowest technical debt. When you are a developer with a story and likely to spend an ephemeral period in an area of the code you are less likely to excite your "ownership mentality". My good friends at 60innovations call this "Owned & Operated" others call this "You built it, You run it". Either way one of, if not the, best outcomes of a Pivot is ownership and love for an area of code.

As I've found with having children there can at times be a fine line between love & loathe so being in that ownership space of something that is being really difficult and misbehaving on a regular basis does mean there are things you really loathe and want to change. Pivoted teams who now own say 10 repos as opposed to dipping in and out of 100 repos will start to take control of bad code and debt and create better and more robust software solutions.

If you can adjust teams away from being client solution (project) focused to owning an area of the code base with a more product mindset then your code base will start to improve in it's quality. Not only that you should start to be able to break up the code base into islands of independently releasable code which is often the goal of a Pivot (as you quite likely start in a SOA or full on monolith space).

There are a lot of trusted solutions out there that need to make this shift from Solution/Project to Product (I'd love to talk to anyone that things they need to do this) and whilst I feel that one of the big benefits of this shift is the developer ownership I'm interested in what other people would see as another huge gain?