To Succeed at Change, Attend to the People

     When implementing a large change or "transformation" in a corporation, you can never be attentive enough to the cultural change and the factors required to to make that shift successful.  The larger the corporation, the more attention and vigilance is required.  In fact, when just the thought of transformation is entertained, addressing the culture needs to be central to that conversation.  Why?  The people ARE the company.  Without their buy-in and action, nothing happens.  Well, certainly a lot of money can be spent, and nods and lip service, but then in 3 months, 6 months, 12 months, it's back to business-as-usual.   Think, turning a barge around in a narrow straight vs a speed boat.  Yes.  It's that hard.

      What's interesting is that part of the problem is the very structure of a typical business organization doesn't typically account for successfully shepherding organizational change, so it falls through the cracks.  HR manages the hiring, laying off and employee administrative support.  But HR doesn't tend to be engaged with the machinations of how people work, or dynamics beyond anything egregious.   Technology is often the center of the change - think ERP changes, new production methodologies, new tools - but technology divisions tend to be focused on technology of course, not culture.  And while some technology transformations are quite successful within IT, bringing the rest of the company along typically doesn't happen (again, it's an afterthought, if at all), so there is a rift in how things are done, and the culture gap grows.   The same goes for when change is initiated in any department.  Product may decide to change their process and then message their changes through a series of emails or meetings.  But buy-in?  Grumble, grumble... it's hard to come by.

     The good news?  Adopting change CAN happen.  As I've observed people and behaviors, and researched and initiated change and motivation throughout my career and personal life, I see three key levers to succeeding: 1) Identify what Ken Blanchard coined the "WIIFM"- What's in it for me?  Individuals and groups need to WANT to change, or the initiative is dead in the water.  If how things are working today are fine to someone, why bother?  Usually they aren't, but if they are, then you'll have to do the work to show them why life will be better. Create incentive and urgency.  But be thoughtful about pulling these levers.  Some organizations are constantly crying "Wolf!" and employees have learned to ignore the turnstile of top-down initiatives.  2) Call it 1-A and 1-B. we need to motivate both the heart and logic of people.  Think about it in terms of losing weight.  A person may need to lose fifty pounds.  But if the heart motivation is, I want to lose the weight in order to be able to carry and care for my new grandchild, and the logistics are clear and simple, like: I just need to make the two simple changes of eating dinner a half hour before I normally do, and cut out sodas, suddenly success is more likely.  3) Identify short-term, big impact wins to create social proof and increase motivation.  To extend the weight loss metaphor, I can be accountable with friends (peers) about my goals, and we can create a group goal.  The goal may be to jog around the two mile lake perimeter with our grandchildren in strollers in six weeks.  Then we celebrate the achievement together.  Also, be sure to have the next goal already defined before the first is achieved.  Don't let up - change takes time to set in on a core level.

     There are plenty of other ways to achieve (and fail) at true change adoption.  But the key takeaway here is, don't ignore the culture/people.  Your employees ARE the company, so invest in them.

   

The Great Divide: How Leadership can Transform

For the last two years, I've been on the front lines of the clash between Waterfall Program management, and FrAgile IT development.  And I will tell you the people and results are battle-scarred.  Throw in a hearty dose of blame on all sides, and no one comes out a winner in this war.

How does this happen?  It all starts when IT goes one way and programs run by other divisions don't.  We all know that Agile isn't meant to abruptly start and end with IT, and yet many a business leader tends to want to treat that Agile thing that IT does as an odd indulgence that we need to humor in order to get the work out of developers.  Wacky Aunt Helen's house smells like cats and rotten eggs, but she contributes to the kids' college funds, so so we just smile and nod when she talks about taking in more strays.

From the Program Management end here are some common disappointments:

• Unpredictability
• Missed dates
• Missed requirements
• Lack of trust
• IT is slow and the enemy

From the IT development team side, there are disappointments, just as weighty:

• Pressure to deliver unrealistically
• Poor backlog management by Waterfall product managers
• Sense of failure
• Heavy tech debt that only increases
• "The Business" doesn't understand 

As for results?  Either something weak and half-baked is set to market, or, "We've been waiting for 18 months for IT to finish this project."  No value delivered.  

Then rather than leaning in to a wider level of commitment, executives who are understandably concerned about the board and shareholders, care less and less about this touchy-feely Agile stuff, and more and more about the bottom line.  IT then becomes a paler image of true Agile, and the business divisions become even more adherent to traditional program management, their most inflexible leaders become the most praised for their "standards" and the split becomes a chasm.  

And with blame being thinly disguised via the word "accountability" and the arrows flying across functions and up and down the food chain, now the culture becomes toxic sludge.  

How do we extricate ourselves from this dynamic?  Through leaders who are willing to acknowledge that it's a problem they can solve.  By being courageous enough to commit every division to following a Scaled Agile system- and commit the time it takes to shift to a different paradigm as a company, these leaders can not only stabilize, make predictable, and increase delivery for the company, but they can also draw out talent and retain people who feels energized by their work and their colleagues. 

That's the importance of a thoughtful servant-leader: (s)he can lift and empower an entire organization.  I've seen it happen with some of the most fractured businesses.  That's true transformation.  

Leading with Honesty

The fish stinks from the head down.  Anyone who has ever belonged to an organization or institution has given a knowing nod to this proverb at one time or another.  But if you’re a manager, consider this:  is it possible that perhaps YOU might be that stinky fish?  The inclination is to point the finger, or deny: “My direct reports only pay me compliments,” “I don't get any complaints.” “It's not me, it’s the executive/vendor/company,” etc., etc., etc.

Reflecting on the possibility that you may be causing organizational problems is a bit like signing up for root canal.  No one wants it, but with the prospect of enduring one short-term pain to get to the “root” cause and alleviate another, it’s worth peeling back a layer for a quick examination…

Let's start with why you may only be receiving compliments from your staff.   How many employees do you know who openly critique their managers, directly to their managers?  You hold the keys to the kingdom.  You can hire or fire them.  They need to ensure that they continue to get paid.  Why would they risk giving negative feedback and creating a “shoot the messenger” situation?  Even in companies that claim to have flat org structures, there is hierarchy.  Employees tread lightly when it comes to their bosses.  Don't assume that because you aren't receiving the criticism, it doesn't exist. Chances are, if you create the right forum, a safe place to give and receive feedback, you might be able to cull valuable suggestions for organization improvement that make you and your team better. 

Make time to support your direct reports.  Don't assume that you're empowering them by being laissez-faire and leaving them to solve every problem.  Some issues are systemic or managerial in nature, and need to be solved by YOU.  On the other hand, don't do their jobs for them.  If you are too busy "working" to manage, this is a red flag that you need to balance or step back from your work as an individual contributor and start proactively managing. 

Take a hard look at your org structure, as well as the way you manage.  Have you set up a structure that is creating role confusion or de-motivation among your staff?  Have you allowed a problem to continue at your managerial level that is preventing your staff from succeeding?  Are you truly empowering your staff to drive progress, or have you created a dependency on you as the Single Point of Failure?    

The right training can pay off in spades.  There are a number of good programs; Ken Blanchard’s tried-and-true Situational Leadership can benefit both you and your staff.  But whichever your style may be, remember: stay brutally honest about your own role.  Get feedback.  Schedule your own personal regular Agile retrospective to ensure you stay focused on continue improvement.  Be the kind of leader that truly affects positive change.  

Implementing Agile: You're either in or you're out

There are many reasons an organization’s Agile implementation will stall, abort, or even fail, but I’ll wager that every one of those reasons involves one fundamental underlying missing element: buy-in. 

My quickest successful implementation of Agile was when the Technology Director and I had the greenlight and full empowerment from the CEO and COO to fully change the paradigm of the production division.  Folks within the division were all so worn out from the wheel-spinning and bickering, they were primed to try something new.  Everyone else was told to do it or get out. (A bit harsh, but sometimes a line must be drawn.)  Well, with across-the-board buy-in, that division was transformed in two months, and delivered a large-scale complex project early and bug-free in three. 

And, I’ve experienced the other side of it: initial executive lip service given toward Agile, zero reinforcement across the departments producing a robust dose of grumbling, consistent lack of follow-through, eventual nose-thumbing at the Agilist leaders soon perceived of as the Gestapo, ending in an angry mob cursing and throwing firebombs at this paralyzed, misunderstood beast called Agile.  By the way, this sort of  scenario is most likely to occur in a weak or balanced matrixed organization, which is why I recommend a strong matrix, or a projectized environment, but more on that later. 

There are countless examples, but here's one key concept where buy-in must be present:  MVP or, Minimum Viable Product.  In traditional Waterfall software development, full requirements are gathered, developers are left alone to work, then the final result is delivered.  Break that mold.   EVERYONE needs to think in terms of iteratively delivering a MINIMALLY VIABLE product sprint-by-sprint.  That means, account managers, don’t promise clients, partners and vendors bells and whistles in two weeks, let alone revenue based on those bells and whistles.  Product Owners, don’t focus on building requirements that include the bells and whistles.  Do focus on what basic product will deliver the biggest value in the shortest time.  Developers, don’t think in terms of building out for the next 10 months the perfect database or back-end that can support the product that will be in 5 years.  Do think about building JUST enough of the foundation that will support and deliver that product to be delivered in 2 weeks.  Scrum Masters, nee Project Managers, don't expect to full requirements mapped to a timeline from start-to-finish.  See how that works?  You won’t be delivering the crust of the pie, you’re delivering a tasty sliver of the full pie:  bit of foundation, a bit of filling, a bit of whipped topping, a bit of cherry.  Something your customer can consume at regular invervals, while looking forward to more.

How can you get everyone to jump into the murky deep-end all at once?  There are a number of ways to set up Agile successfully, and though you need full buy-in fairly quickly, to start, you actually only need a some key proponents, executive buy-in, and the rest will become believers soon thereafter, as they start seeing positive results unfolding before their eyes. 

A la Carte Agile

Let’s say you’ve decided that since "agile" means to move fast and quickly adapt, like 72%  of American companies using some version of Agile, you’ll adopt it too…. 

Only it’s too much to commit to preparing stories (can’t we just call them product requirements?) in advance of a sprint because you never know how the market will change or what the vendor will deliver.  And you can’t really fill the three roles (Scrum Master, Product Owner, Delivery Team) because you have folks who wear a lot of hats, and you don’t have the resources to nail down dedicated teams.  And how is it “agile” to require that the product owner lock down what needs to be done before a sprint?  That doesn’t sound flexible.  The team should be able to change direction at any point in any cycle.  And you really can’t require your developers to spend all that time in these warm, fuzzy meetings that Agile calls, “ceremonies.” That’s a waste of time. And certainly your developers need to put careful thought into building the foundation of the software, so really, sprint cycles should allow for continued work from cycle to cycle without unreasonably requiring folks to deliver end-to-end in two to four week sprints.  Other than that, you are 100% behind whatever those crazy team leads what to do.  By all means, go, agile!  Fast and nimble! 

Hard reality: when you take out any of these factors, you’re not really doing Agile development.  You’re doing some sort of hybrid of Agile and Waterfall, and that can be okay; you certainly may end up making  improvements by implementing some, but not all of the system.  I’ve done it, and it’s the preferred alternative to mayhem. But you’re not making a full paradigm shift to true transformation, and you’ll continue to experience foundational roadblocks. 

People confuse the formal title of the methodology “Agile” with the lower case “a” adjective, “agile.”  While the methodology does allow organizations to be agile, as in nimble, it’s not without structure, and specific process.

Save yourself and your organization unneeded, drawn-out heartache by ripping off the bandage as quickly as possible, adhering to the fundamentals and diving into the benefits right away.

This isn’t the agililty I signed up for….

We’ve trained up on Agile, now let’s get back to work.  There’s not a minute to lose! 

This can’t be right, say Executives and Product Managers.  We’re supposed to be able to tack from minute to minute because the market calls for reactivity and hairpin turns.   

This can’t be right, say the developers. We’re supposed to be able to develop in a dark corner until we deliver the full product you asked us to built.  We should be left alone for the next two years, if need be.

At first it may seem a disappointing compromise to both the "business" and development, but Agile finds the healthy intersection of the two extremes.  Development DOES take time and focus.  If an organization does not allow for that, only the smallest implementations, and very little truly innovative work can be developed.  The market DOES require adaptivity and quick shifts.  If that doesn’t happen, viable products aren’t delivered, revenue isn’t generated, companies fold. 

So, what would happen if we time-boxed development cycles so that every 2-4 weeks, we could depend on developers to built a Minimally Viable Product (MVP)?  Not the whole kit and caboodle with all the bells and whistles, but just the essentials.  Let’s say we were developing an app for finding the best business blogs?  We might first build a simple search interface using Google that tracked down most trafficked sites with the top three keywords.  That’s it.  Nothing more.  Developers would have 2 business weeks to focus only on that small manageable development task.  Then Product Owners and management would have a complete and deliverable product to get out to the consumers after 2 weeks.  Is two weeks fast enough to deliver a product to market?  Most would say yes.  Is 2 weeks of uninterrupted development time long enough to do some version of valuable work?  Most would say yes.  

Your team will likely be initially uncomfortable adapting to the Agile paradigm, but stick with it.  Everyone will be feeling the benefits soon enough.

Is there a manager in the house?

We’ve all seen it: So-and-so has a manager title, and the whispered comments begin floating about the office, “What does So-and-so actually DO?”  It’s the classic upper management go-to:  promoting the SME or the technician to a management position, or hiring up a tennis partner, college buddy, or the guy from the last startup who single-handedly “managed” a guerilla implementation of that quick-sell app that got everyone cashing out fast.   

Don't be too hard on your leadership. It's human nature to rely on the people we know or have relied on previously; still, all of these hiring decisions assume one consistent fallacy: that management is innately easy. 

It’s unfortunate that SMEs/individual contributors don’t have a way to move up in title and salary by adhering to what they excel at.  Instead, organizations require that they manage.  The genius who unraveled and re-configured code in a way that leapfrogged two generations in front of what is currently in the market, is also assumed to also have the skills to manage and communicate risk to a project, or mentor employees.

Executives tend to get a bad rap when they hire cronies to run departments.  Back room bar deals and golden parachutes come to mind.  But even the most self-focused business leaders have a laser-sharp focus on generating a successful business that turns a profit.  So it’s safe to say that very few would hire a friend thinking, "There's no way he can do the job, but, oh well."  The same goes for hiring a great executor as a manager.  The most common assumption is:  of course a strong executor can build and manage a team of strong executors.  It ain't necessarily so. 

What business leaders frequently fail to realize is that effective management has its own set of skills that are distinct from other business skills.  To make matters more complex, these tend to be soft skills that are often difficult to identify and hire for: situational leadership abilities, varying approaches to decision-making, project and risk management, the full spectrum of communication skills.   Probably over and above all of these is the discernment to identify the best approach after speed-analyzing data points in an ever-changing problem set. The best managers have analytic skills and a high degree of social intelligence, with a proclivity toward servant leadership. 

And you know what, even when you have a manager like this, the file room conversations might still include the question, “What do they actually DO?”  Why?  Because if things are going right, they aren't generating all the deliverables, nor are they constantly in firefighting mode.  A good manager will have subject matter expertise, but will distribute work to their teams, empowering them to be the best they can be, and making sure the trains are running smoothly.  They are transparently communicating the work their team is doing, the roadmap ahead, and the ROI at all times, up, down and across the food chain.  This is often quiet, behind the scenes hard work. 

To my mind, the best managerial KPI would be something akin tothe plus/minus rating in sports.  The +/- rating tells us: did the team gain or lose points when that player was on the court/field/ice, and if so, how many?  That player may not have had their hands on the ball when the point was scored, but these are the key behind the scenes playmakers, setting up others in the team for success.  

So next time someone asks, “What does Manager X do?,” look carefully.  Maybe nothing.  But maybe that person is exactly the kind of manager you want on your team.