Tag Archive for culture

Managing for DevOps

This was originally published on the Amalgam Insights site in July of 2018

I am constantly asked the question “What does one have to do to implement DevOps”, or some variant. Most people who ask this question say how they have spent time searching for an answer. The pat answers they encounter typically is either technology based (“buy these products and achieve DevOps magic”) or a management one such as “create a DevOps culture.” Both are vague, flippant, and decidedly unhelpful.

My response is twofold. First, technology and tools follow management and culture. Tools do not make culture and a technology solution without management change is a waste. So, change the culture and management first. Unfortunately, that’s the hard part. When companies talk about changing culture for DevOps they often mean implementing multifunction teams or something less than that. Throwing disparate disciplines into an unregulated melting pot doesn’t help. These teams can end up as dysfunctional as with any other management or project structure. Team members will bicker over implementation and try to protect their hard-won territory.

As the old adage goes, “everything old is new again” and so-called DevOps culture is no different. Multi-functional teams are just a flavor of matrix management which has been tried over and over for years. They suffer from the same problems. Team members have to serve two masters and managers act like a group of dogs with one tree among them. Trying to please both the project leader and their functional management creates inherent conflicts.

Another view of creating DevOps culture is, what I think of as, the “CEO Buy-in Approach”. Whenever there is new thinking in IT there always seems to be advocacy for a top-down approach that starts with the CEO or CIO “buying in” to the concept. After that magic happens and everyone holds hands and sings together. Except that they don’t. This approach is heavy handed and an unrealistic view of how companies, especially large companies, operate. If simply ordering people to work well together was all it took, there would be no dysfunctional companies or departments.

A variation on this theme advocates picking a leader (or two if you have two-in-the-box leadership) to make everyone work together happily. Setting aside the fact that finding people with broad enough experience to lead multi-disciplinary teams, this leads to what I have always called “The Product Manager Problem.” The problem that all new product managers face is the realization that they have all the responsibility and none of the power to accomplish their mission. That’s because responsibility for the product concentrates in one person, the product manager, and all other managers can diffuse their responsibility across many products or functions.

Having a single leader responsible for making multi-functional teams work creates a lack of individual accountability. The leader, not the team, is held accountable for the project while the individual team members are still accountable to their own managers. This may work when the managers and project team leaders all have great working relationships. In that case, you don’t need a special DevOps structure. Instead, a model that creates a separate project team leader or leaders enables team dysfunction and the ability to maintain silos through lack of direct accountability. You see this when you have a Scrum Master, Product Owner, or Release Manager who has all the responsibility for a project.

The typical response to this criticism of multi-functional teams (and the no-power Product Manager) is that leaders should be able to influence and cajole the team, despite having no real authority. This is ridiculous and refuses to accept that individual managers and the people that work for them are motivated to maintain their own power. Making the boss look good works well when the boss is signing your evaluation and deciding on your raise. Sure, project and team leaders can be made part of the evaluation process but, really who has the real power here? The functional manager in control of many people and resources or the leader of one small team?

One potential to the DevOps cultural conundrum is collective responsibility. In this scheme, all team members benefit or are hurt by the success of the project. Think of this as the combined arms combat team model. In the Army, an multi-functional combined arms teams are put together for specific missions. The team is held responsible for the overall mission. They are responsible collectively and individually. While the upper echelons hold the combined arms combat team responsible for the mission, the team leader has the ability to hold individuals accountable. Can anyone imagine an Army or Marine leader being let off the hook for mission failure because one of their people didn’t perform? Of course not, but they also have mechanisms for holding individual soldiers accountable for their performance.

In this model, DevOps teams collectively would be held responsible for on-time completion of the entire project as would the entire management chain. Individual team members would have much of their evaluation based on this and the team leader would have the power to remediate nonperformance including remove a team member who is not doing their job (i.e. fire them). They would have to have the ability to train up and fill the role of one type of function with another if a person performing a role wasn’t up to snuff or had to be removed. It would still be up to the “chain of command” to provide a reasonable mission with appropriate resources.

Ultimately, any one in the team could rise up and lead this or another team no matter their specialty. There would be nothing holding back an operations specialist from becoming the Scrum Master. If they could learn the job, they could get it. The very idea of a specialist would lose power, allowing team members to develop talents no matter their job title.

I worked in this model years ago and it was successful and rewarding. Everyone helped everyone else and had a stake in the outcome. People learned each other’s jobs, so they could help out when necessary, learning new skills in the process. It wasn’t called DevOps but it’s how it operated. It’s not a radical idea but there is a hitch – silo managers would either lose power or even cease to exist. There would be no Development Manager or Security Manager. Team members would win, the company would win, but not everyone would feel like this model works for them.

This doesn’t mean that all silos would go away. There will still be operations and security functions that maintain and monitor systems. The security and ops people who work on development projects just wouldn’t report into them. They would only be responsible to the development team but with full power (and resources) to make changes in production systems.

Without collective responsibility, free of influence from functional managers, DevOps teams will never be more that a fresh coat of paint on rotting wood. It will look pretty but underneath, it’s crumbling.

Google Should Not Have Fired Their Engineer over Sexist Memo

A pig.

Anyone who knows me personally knows my politics are generally liberal sprinkled with a strong respect for tradition. I also am willing to label myself a feminist in the traditional sense of the word – an advocate for the equality of women in all aspects of society. The reason I mention this is to provide context for my contention that Google was wrong to fire an employee for his wrongheaded remarks about women in tech. And also, to head off arguments that I am some right-wing, women bashing, pig.

Like many in the tech community, I have been following the story of Google engineer James Damore’s internal memo entitled “Google’s Ideological Echo Chamber”. I was taken aback by two aspects of the memo: how well written it is and how weak the data is. In most cases, Mr. Damore does rely on stereotypes and not real data. That makes his arguments less than defensible. Firing him for those arguments though, is draconian. Google action also helps to prove Mr. Damore’s point about the intolerance of views that don’t meet with, what he perceives, as a left leaning bias. Let me put this another way – you don’t fire someone because you find their views odious. That’s not liberal. Liberals revel in freedom of thought and respectful public discourse. Mr. Damore sought out a dialog and, in this case, is more “liberal” than Google management.

Unfortunately, Google also missed a rare opportunity to discuss gender stereotypes and the biases they drive. That would have been a great service to Google, the tech industry, and society at large. It may have been a teachable moment not just for Mr. Damore but for everyone in tech who believe we are untouched by the hidden biases of the greater society. Here’s where the scientific literature may have helped. Mr. Damore’s fellow Googlers (Googlites? Googles? Whatever…) could have used reason to dispel his notions about gender, citing real scientific fact and respected data. He does not come across as an unreasonable person, just lacking in appropriate facts. Politely pointing out where the research doesn’t support his ascertains may have swayed him and any other readers who hold the same views.

Change almost never happens by silencing critics who act in a respectful manner and ask for dialog. It only provides a bigger soapbox from which to pronounce distorted views. Change happens when we learn from each other, something that Mr. Damore says he is open to. Removing him doesn’t remove his point of view. Googlers who share his views won’t suddenly abandon them. Instead they will see evidence that he is right and Google is biased against dissenting viewpoints.

Ultimately, Mr. Damore asked for a discussion. Wouldn’t that have been better approach? Legalities aside, removing someone from their livelihood is harsh. It is especially so when he was encouraged to share his views openly. By firing Mr. Damore, Google seems to prove his point that the company may be authoritarian, biased, and intolerant. It’s just too bad that Google missed an opportunity to prove him wrong – wrong about Google and wrong about women in tech.

I certainly don’t agree with Mr. Damore. My 33 years in the tech industry (which are likely a few more than his) have taught me that women engineers are every bit as capable as men. That more women are not in tech has more to do with a company culture that is not family friendly and managers with views such as Mr. Damore’s, than the ability of women to do the job. That doesn’t mean that he should be fired for having these views, even if they are antediluvian. Instead, respectful discourse would have accomplished so much more.