Leadership

Is Your CIO Your CDO?

by

One analyst reports that by 2015 25% of companies will have a Chief Digital Officer (CDO) who resides outside of the IT department and is responsible for driving the digitization of research and development, marketing, customer service and the creation of new products and services. Before you create this new role and contact your favorite executive recruiters, take a step back and ask a few questions: What is the scope of digital transformation for your […]

How to Become a Hero for Growth

by

One thing that happens when you work to develop change across an organization: you detect the “cultural” elements of an organization that often go unnoticed by the people involved.  Just as a “Fish discovers water last,” people working in a cultural context can be fairly unaware of the implications of their culturally influenced decisions.  “It’s the way we’ve always done it, here.”

One cultural influence that I’ve seen, quite often, in organizations that are struggling to grow past a particular size, is the “culture of heroes.”  This pattern of behavior has the following smells:

  • Whenever there is a problem with the servers, call Jack.  While it isn’t his current job, he’s the one who installed and designed the server environment, so he’s the logical one to fix it.  (Extend this beyond “the servers.  For every “area” of the system or the business process, there is a “person” who is the “hero” who can solve problems with that area.  There’s often an “uber-hero” above them all, who has to be called in for every emergency no matter what).
     
  • If someone asks me to do my job differently, I refuse until my manager specifically approves the individual change.  After all, my manager has done this job for years and years, and he or she knows best how to do it.
     
  • If I’m a hero or a manager, and I make a casual remark in a meeting that I want to have control over some minor aspect of a process, a subtle but IMMEDIATE shift occurs so that the process now has an extra step: to ask me for my approval of that minor aspect (even if it is something that has little or nothing to do with my actual accountabilities).
     
  • If an important new project is starting, the kickoff meeting cannot proceed unless a couple of heroes are in the room.  Absolutely no way.
     

These are signs of a culture of heroes.

And they are a big problem. 

Let’s first recognize that, for any snapshot of 100 people in the same role, there are two or three that have risen up to become well respected experts.  There are 20 or so that can lead a group, and the rest are following.  One of those “folks in the rest” may mature, of course, and may be ready in the future to lead or become one of those well respected experts.  These are not labels.  But, at any one point in time, the ratios often work out this way.

This is human nature.  Nothing wrong with that.  The problem comes when you feed it.

As a leader, you cannot avoid a variation in skills and experience.  However, the true leader recognizes that there are people who want to grow.  He or she will want to create an intentional culture that not only fosters that growth, but encourages individuals who are the experts to “step aside” a little, and allow the non-experts to have a chance at solving tough problems. 

If your culture keeps coming back to a handful of heroes, no one else in the team can grow.  The people who naturally WANT to grow will leave.  And you are left with an organization of people who don’t want to grow.

If no one in your organization wants to grow, the organization won’t grow.  Plain and simple.

Not only that, your organization won’t evolve.  It won’t improve.  It won’t optimize.  It won’t do ANYTHING interesting or new.  That’s because all the people who could benefit by change, all the people who have fresh ideas and novel approaches and interesting influences, have run away to other organizations where they can try those ideas out. 

And that is what the culture of heroes does… it kills the spark of change in a group of people.

So don’t let the heroes stunt the growth of your organization.  Look around.  If you have heroes who usually get called, ask THEM to be heroes in a different way… heroes for growth.

A hero for growth makes this decision:

  1. I listen when someone brings me a problem.
  2. I consider whether the person who has the problem should be empowered to solve it.
  3. I consider whether the possibility of them “doing it wrong” means that they will cost a great deal of money or some other business loss. 
  4. Then, I take the DEFAULT position of “let the person closest to the decision make it.” 
  5. I only take on a challenge if the people who should be doing it are asking for my help.  (Not their managers, or their peers, or their staff.)  And when I do, I take the attitude that I want to help that person grow… so I challenge them, include them, and inspire them.  When things work, they get credit.  When things fail, I take part of the blame (giving them a safe space to grow).  I don’t override them, belittle them, or ignore them.  I never ever point fingers.

 

If you are a hero in your organization, I challenge you right here to become a hero for growth.  Who knows… you may change your culture just by your leadership, and your example.

Unraveling the Developer Bias in Agile Development Practices

by

There is a contradiction that shows up in many books and articles on agile software development.  .  And I’m going to rant a little on one of them: the “developer” bias in Agile software practices.

Before I begin my rant, I’d like to tell you where it comes from.  I am an Enterprise Architect.  I am also an agilest.  I am a certified Scrummaster (for many years) and have been on many agile projects.  I’ve seen success, and I’ve seen failure.  I know that agile is good, but not good enough to overcome people who are determined to undermine change. 

I am currently engaged on a project to help an organization rewire their business processes.  All of their core processes.  Some of them are in software development… and that is where agile comes in, but some are in other areas (sales, account management, customer service, etc).  I see it all, not just the software engineering bits.

To make this work, we created a set of principles that we use to drive the conversation around transforming the company.  We train people on the principles.  We connect change to the principles.  The principles are developed from the agile mindset but are not the same as the ones traditionally tied to the agile manifesto. 

One is focused heavily on the notion of an empowered team.  As the trainer, I’ve embedded these principles into my head.  Kinda hard not to.  So when I’m reading a book on agile practices, and the author says something that violates one of these principles, it stands out.  Big time.

And hence the rant.  I was reading Mike Cohn’s book on agile stories and I came across a passage that reflects a kind of mindset that does NOT build empowered teams.  And I went off.  The rest of this post is my rant.

—

On one hand, there is a basic expectation that we should empower the team to solve their problems using their skills and training.  On the other hand, there is a bias towards having developers involved in every part of a business process, from sales through requirements to project management and out to delivery and customer service.  The net result: we are empowering developers to perform every role.  No one else is empowered.  They are, in fact, not trusted at all.

At some level, agile practices like XP and Scrum are written, and promoted, by software developers, so it is understandable that these authors believe that software developers are a necessary part of every process.

But they are not. 

So what’s the problem

Organizations intentionally create specific roles and groups of people.  Those roles are defined to take the most advantage of the intrinsic motivations of people when performing their duties.  The things that motivate a person to become a project manager, for example, are rarely the same things that motivate a person to become a software engineer.  Motivation matters. If you are not motivated to excellence, you will not perform with excellence.

While it is fine for an individual person to be able to perform well in a couple of roles, it is absurd to build a system or business process that expects all people in one role to be able to perform another role well.  In specific, it is absurd to build processes where a technologist is required to develop requirements, or manage a project, or plan the delivery of systems.  Those processes can be performed just fine with motivated people who are trained and experienced in those activities.  However, to empower a team, people in these roles must be respected as well. 

Agile software, that so values people over processes and tools, demonstrates an utter lack of respect for the individuals who choose to excel in non-technical roles by asserting the need for developers to be involved in every step of their process.

For example, in XP (and sometimes in Scrum), user stories are described as being developed by a “customer team” that includes developers.  In the book “User Stories Applied,” Mike Cohn describes a process where a series of user roles are developed.  From those roles, the stories will be drawn.  The following is a quote from the book:

To identify user roles, the customer and as many of the developers as possible meet in a room with either a large table or a wall to which they can tape or pin cards.  It’s always ideal to include the whole team for the user role modeling that initiates a project, but not necessary.  As long as a reasonable representation of the developers is present along with the customer, you can have a successful session. — “User Stories Applied” by Mike Cohn

I’m an agilest, and this statement takes my breath away.  Why?  Because the SKILL of developing user roles is a good skill to have, but not a necessary skill for all developers to have.  Yet the author (whom I respect) assumes that the activity cannot be performed successfully without developers in the room!  At the same time, the text assumes that the task can be performed by developers exclusively (no one else is necessary at all).

The time that we spend training developers to be good at creating user stories is time that we are NOT spending training them on concurrent processing, idempotent messaging, and query optimization.  We don’t train business analysts or engagement managers on C# design patterns, so why should we train developers on user role modeling and requirements analysis?  It’s a total lack of understanding of the value of roles, and it is a bias that works against success.

What’s the solution: respect

 

Roles are not boundaries.  In any team, there are roles.  More importantly, as a member of a team, I have to trust my team members to fulfill their roles well.  If they need help, I TRUST THEM TO ASK FOR HELP.  When they do, I am happy to “cross roles” and provide help.  When I provide help, I am doing so from the perspective of a less-skilled resource, and under the supervision of the accountable role.  (e.g. if I “help” a tester, but don’t document a defect according to team standards, how much “help” am I actually providing?)

Roles are empowering.  If my team member does not ask for help, I trust each one to perform his or her role with excellence.  If I don’t trust them, how can they develop the excellence that the company expects?  How can they be recognized and rewarded for excellence if our processes and methods show a lack of trust in their roles to perform well without a developer present? 

Roles demonstrate respect.  As an agilest, I value people over processes.  That means I value the contribution of individual experts on my team to do their work with excellence, and I will show them respect for the work that they do, and the unique value that they contribute.  I will do so by allowing them to do their work without the “supervision and assistance” of a developer.

If they need me, they will ask for me.  Until then, I will get to doing what I do best.  I have a job to do, after all… and it is mine to do well.

Why this matters

Agile software development solves a problem.  The problem is that we are including waste in our processes, and that waste is causing software to be delivered late or with poor quality. 

If we optimize our processes, we can reduce waste. If we include developers in every process, we are not optimizing our processes.  We are, in fact, replacing one kind of waste with another. 

Has in-person communication become the unwilling victim of technology?

by

In Enterprise Architecture, one of the most important aspects of the job is not only to communicate, but to lead change.  In other words, it is great to have the data to point to a problem in an enterprise.  It is better to help that enterprise overcome it by changing something (processes, technology, training, staff levels, departmental structures, roles and responsibilities, artifacts, governance mechanisms, etc).  Change requires more than simple communication.  It requires a kind of in-person, face-to-face, listening and hearing and absorbing interaction that is difficult or impossible over written mechanisms like e-mail, word documents, and powerpoint presentations.

Our technology has led us to the point, in modern business, that we consider outsourcing and remote work to be a net benefit for all involved, but each of these “distance” mechanisms introduces the RISK of poor communication.  That risk is magnified when the person on one end of the line is hoping to change something that the person on the other end is doing.  Change is harder across distance, and that difficulty becomes magnified when dealing with the array of different interactions that are needed at the enterprise level.

I wonder if the PC revolution, that brought us personal access to written communication, has created a deep reliance on written communication in corporate processes.  I wonder, further, if that access to technology isn’t directly harming our ability to look a person in the eyes and communicate with them.

As a culture, we have moved from the age of face-to-face all the way to text-messaging-someone-in-the-same-room in the course of a single generation. 

Enterprise Architecture is more difficult because of this shift in communication patterns.  All forms of face-to-face communication are hampered by it.

Modern technology has done more to damage interpersonal communication than any other paradigm shift in human history.

This worries me.

Implementing Organizational Structure and Focus

by

When I joined the IT Department at the American University of Sharjah as the Director, I was presented with an organizational structure challenge.  I found out that I had 21 direct reports and that my department did not have a concept of operational management!  I had just come from being the Manager, Business Application Services […]

The post Implementing Organizational Structure and Focus appeared first on Enterprise Architecture in Higher Education.

My First 180 Days as a CIO

by

Hard to believe that time has gone so quickly in my CIO role.  On March 17, 2013 I have been the Director of Information Technology at the American University of Sharjah in Sharjah, United Arab Emirates for 180 days. It has been a huge change for me especially after spending 20 years at the British Columbia […]

The post My First 180 Days as a CIO appeared first on Enterprise Architecture in Higher Education.

Line-In-The-Sand Leadership

by

We know that attitude, culture, and engagement underpin the performance of a team.  Despite knowing this, the announcement yesterday that four key players in the Austalian cricket squad currently touring India will be excluded from selection to play in the third test-match of the series was chillingly clear and startlingly decisive1,2. Together, the coach, captain, […]

Understanding the Strategy Diffusion Problem

by

“Everyone is trying to do their best but they don’t fully understand our strategy. As a consequence, we are getting better and better at things that don’t matter.” Senior Business Manager While most leaders have a good idea of what they want their organizations to do, they struggle to translate their vision into focused and […]

Planning the contribution of the leader among architects

by

In an earlier post I’ve laid out the Wheel of Leadership as a tool for the leader among architects. In this post I’ll visualize some of the approaches one can have as one employ the Wheel of Leadership. Pure forward flow In the pure forward flow each part of the wheel of leadership is addressed […]

Strong CIO, C-suite Relationships Drive Growth

by

Your ability as a CIO to cultivate strong relationships with your C-suite peers is paramount to your professional success in an environment where IT is expected to generate revenue and enhance the customer experience. But more than your career longevity is on the line. The profitability of your company is at stake. As part of our 5th Annual Digital IQ survey, we asked more than 1,100 business and technology executives from 12 countries to rate […]