“Culture is a Lie,” Paul Czarkowski – Highlights

A good, and fun talk from Paul. He tries to refocus DevOps-y energy from “culture change” to more practical things for individuals to do.

Highlights:

  • You can’t change culture from the bottom. Leaders change the culture, they define it.
  • Culture is behavior.
  • If you want to change culture, you need to change your leadership.
  • Culture: as a practitioner, you can’t change it. And if you’re in a leadership position, you’re incentivized not to change it.
  • “If you choose to die on a hill, you’re gonna die on that fucking hill.”
  • Corollary: “If you don’t decide to die on a hill, you won’t die on that hill.”
  • Generative orgs can create microservices.
  • Others will make monoliths.
  • Most people spend more time justifying not working than working.
  • People who do good work will be pulled down.
  • Most people around you aren’t bad people, they’re just a product of their surroundings.
  • As soon as you start fighting the organization, it’ll start fighting back harder than you.
  • Often said: if your company is acquired by a larger company, leave.
  • Then, some examples of automating governance.

Link: Strong Opinions Loosely Held Might be the Worst Idea in Tech

On a certain kind of team, where everyone shares that ethos, and there is very little power differential, this can work well. I’ve had the pleasure of working on teams like that, and it is all kinds of fun. When you have a handful of solid engineers that understand each other, and all of them feel free to say “you are wrong about X, that is absolutely insane, and I question your entire family structure if you believe that, clearly Y is the way to go”, and then you all happily grab lunch together (at Linguini’s), that’s a great feeling of camaraderie.

Unfortunately, that ideal is seldom achieved.

Source: Strong Opinions Loosely Held Might be the Worst Idea in Tech

Link: The problem with being a long-term expat

Karen, a British citizen now in Malaysia, who prefers to be known only by her first name because her husband works for a large multinational, recalls their 22 years on the road became more difficult as their children got older. Both are now at university in the UK. Having never lived in Malaysia, they don’t see it as home, and their actual home in Europe is rented out. “Their home is out of a suitcase,” Karen says.

Source: The problem with being a long-term expat

Americans smile a lot

Just as it is easy to misinterpret the reason for an icebreaker activity, it’s easy to mistake certain social customs of Americans that might suggest strong personal connections where none are intended. For example, Americans are more likely than those from many cultures to smile at strangers and to engage in personal discussions with people they hardly know. Others may interpret this “friendliness” as an offer of friendship. Later, when the Americans don’t follow through on their unintended offer, those other cultures often accuse them of being “fake” or “hypocritical.”

Also:

…[a] Russian saying “If we pass a stranger on the street who is smiling, we know with certainty that that person is crazy . . . or else American.”

From The Culture Map

See more…

DevOps, monolithic architectures, craftsmanship – an unpublished interview

I’m too wordy when I reply to reporters. This is mostly true everywhere I produce content. I don’t like trite, simple answers. Brevity and clarity makes me suspicious, especially on topics I know well. As a consequence, I don’t think this interview by email was ever published.


What’s a DevOps advocate?

If you mean what I do, it means studying  people and organizations who are trying trying to improve how they do software, summarizing all those, ongoing, into several different types of content, and then trying to help, advise, educate people on how they can improve how they do software. A loop of learning and then trying to teach, in a limited way. For example, I’m working on finish up a book that contains a lot of this stuff that I’ve found over the past couple of years.

What is the foundation of DevOps: automation, agility, tools, continuous or all of them?

Yes, those are the core tools. The traditional foundation is “CALMS” which means Culture, Automation, Lean, Measurement, and Sharing. Ultimately, these are things any innovation-driven process follows, but they’re called out explicitly because traditional IT has lost its way and doesn’t usually focus on these common sense thing. A lot of what DevOps is trying to do is just get people to follow better software development and delivery practices…ones they should have been doing all along but got distracted from with outsourcing, SLAs, cost cutting, and the idea of treating IT like a service, or utility rather than an innovation engine for “the business.”

Anyhow, CALMS means:
  • Culture – the norms, processes, and methodology IT follows. You want to shift from a project delivery culture to a product culture, from service management to innovation. Defining “culture,” let along how to change it and how to use it is slippery. I wrote up what I’ve figured out so far here.
  • Automation – this is the easiest to understand of all the DevOps things. It means, to focus on automating as much as possible. If you find yourself manually doing some configuration or whatever, or relying on people opening a ticket to get something
  • (Like a database, etc.), figure out how to automate that instead.
  • Lean – software development has been borrowing a lot from Lean for the past 15 years. DevOps takes most all of it, but the key concepts it brings in are eliminated waste (effort spent that has “no value” to customers, in IT, often wait time for things like setting up servers and such) and working on incremental, more frequent (like weekly) releases rather than big, yearly releases.
  • Measurement – DevOps, like agile, is actually very disciplined if done properly. In addition to monitoring your applications and such in production, in order to continuously improve, DevOps is interested in measuring metrics around process. How many bugs are in each release? How frequently do we deploy software? And so forth. The point is to use these measurements to indicate areas of improvement and figure out if you’re actually improving or not.
  • Sharing – this was added after the initial four concepts. It’s straight forward and means that people across groups and even across organizations should share knowledge with each other. It also means, within organizations, having more unified teams of people rather than different groups that try to work with each other.
Today, we can ship every day. What impact for the teams and developers?

Shipping more frequently means you have more input on the usefulness of your software and it also adds much more stability and predictably into your software process. Because you’re shipping weekly, or daily, you can observe how people use your software and make very frequent changes to improve your software. There’s a loop of trying our a new feature, releasing it and observing how people use it, and then coming up with a new way to solve that problem better.

Stability and predictability are introduced because you establish a realistic rate of feature delivery each week. When you’re delivering each week, you quickly learn how much code (or features) you can do each week. This means that rather than having developers estimate how many features they can deliver in a year, for example, you learn how much they can actually deliver each week. Estimates are pretty much always wrong, and complete folly. But, once you calibrate and know how many features the team can deliver each week, they’re predictable and the overall process is more stable.

Monolithic’ architecture vs modular’ approach. Are we talking micro-service? Container?

Yes, a monolithic architecture implies software that’s made of many different parts, but that all depend strongly on each other. To be frank, it also means software that’s complex, poorly tested, and, thus, not well understood. “Monolith” is often used for “software I’m scared to change,” that is, “legacy software.” In contrast, if you’re fine to change software and don’t fear doing so, you just call it “software.”

A microservice architecture is the current approach to break up “monoliths” into more independent components, different services that evolve on their own but are composed together for an application. Buying a product online is a classic example. If you look at the product page, it could be composed of many different services: pictures of the product, figuring out the pricing for your region, checking inventory for the product, listing reviews, etc. A monolithic architecture would find all of that information all at once, in “one” piece of code. An application following a microservices architecture would treat all of these things as third party, not under your control services and compose the page from calling all those services.

To over simplify it, we used to call this idea “mashups” in the Web 2.0 era: pulling data from a lot of different sources and “mashing” that data up into a web page. All the rotating ads and suggested content you see on news sites are a metaphoric example as well: each of those components are pulled in from some other service rather than managed and collected together by the news site CMS. This is why the ads and suggested content are often awful, of course: there’s no editorial control over them.

Infra as Code? Another thing?

“Infrastructure as code” means using automation tools the building and configuring of servers (the software parts, not the hardware) and other “infrastructure” and then treating those automation workflows as if they were software code: you check them into version control and track them like a version of your application. This means that you can check out, for example, a version of the server you’re configuring and automatically create it. The point of doing this is get more visibility and control over that configuration by removing manual, human-driven configuring and such. Humans create errors, forget how things were done, have bad hair days, and otherwise foul things up. Computers don’t (unless those annoying humans tell them to).

For you, what is the ideal architecture?

An annoying, though accurate answer would be “it depends. I don’t really code anymore, so I couldn’t really say. Usually, you start with the minim needed and just add in more complex architectures as needed. That sounds like the opposite of architecture, but it’s worse to end up with something like all those giant, built out cities that end up having few people living in them.

Kanban, craftsmanship: friend or enemy of DevOps?

Kanban is used a lot in DevOps, maybe not fully. But, the idea of having cards that represent a small feature, a backlog that contains those cards ranked by some priority, and then allowing people to pull those cards and put them in columns marked something like “working on” and “complete” is used all the time.

I’m not sure what “craftsmanship” is in this context, but it it means perfecting things like some master furniture maker, most DevOps people would encourage you to instead “release” the cabinets more frequently to find out how they should be designed than assuming you knew what was needed and working on it all at once: maybe they want brutalist square legs instead of elegant rounded legs topped with a swan.

 

And, of course, if “craftsmanship” means “doing a good job and being conscious of how you’re evolving your trade,” well, everyone would say they do that, right? :)

Link: It’s Not a Digital Transformation Without a Digital Culture

Signaling change with symbolic acts that embody the new culture is a good way to activate leadership characteristics quickly. For example, companies can designate meeting-free days to emphasize greater focus on action over planning, or they can give engineers a cash allowance to buy their own desktop equipment to demonstrate trust. Sometimes even a bold move, such as firing people whose behavior is antithetical to the new culture, is warranted. To signal change at Cisco, executives in certain divisions gave up their offices so the company could create team rooms; the company also started allowing employees to choose the workspace and tech tools that best fit their individual roles. The CEO of the North American software provider cited earlier began sending notes to employees who are praised by name in customer reviews. Such acknowledgment serves as an example of how company leaders can reinforce the customer-first mindset that’s central to the company culture. 

And more leadership tactics from BCG.
Original source: It’s Not a Digital Transformation Without a Digital Culture

Link: When Culture Doesn’t Translate

Unfortunately, the Thai manager told me, his U.S. colleagues usually didn’t send the agenda until an hour before the call, so his team was unable to prepare. And it struggled to understand what was said during the call, because the U.S. participants spoke too quickly. He also said that the Americans rarely invited comments from the Thais, expecting them to jump into the conversation as they themselves would. But that kind of intervention is not the norm in Thailand, where it is much less common to speak if not invited or questioned. The Thai manager summed up his perspective this way: “They invite us to the meeting, but they don’t suggest with their actions that they care what we have to say.” The Thai team members ended up just sitting on the phone listening—giving the Americans the impression that they had nothing to contribute or weren’t interested in participating.
Original source: When Culture Doesn’t Translate

Link: Digital Transformation: Why Culture Is So Key

Culture is the most important factor, way more important than technology, for example. By culture, we mean a set of shared values and beliefs that drive a change in behaviors. This has to be both a top-down and a bottom-up approach. The CEO and the C-level executives must embody the culture and the DNA of the brand so that employees change their behaviors to better serve their clients. A great example of this was shared by Frédéric Oudéa, the CEO of Société Générale, when receiving the 2018 prize (see picture below): He regularly (once a month) spends time learning how to code in order to understand IT/software issues and directly listen to clients and employees. Another example comes from C-level executives at Generali or Air Liquide, which spend time regularly to call back detractors themselves.
Original source: Digital Transformation: Why Culture Is So Key

Link: Lessons from the UK Government’s Digital Transformation Journey

It’s probably OK:

In any organisation that’s been around for a while, ways of doing things build up and often disconnect from the reasons they were put in place. Things are cited as “rules” which are really just norms. We had to get really good at working out the difference, and on pushing back on some of those rules to get to the core principles.

Get involved with the backend people:

I know of one government project where the digital team couldn’t even add one extra textbox to their address fields, something users were complaining about, because the backend IT teams were too busy to make the change.

Working with the end user changes staff for the better:

I’ve talked to a lot of teams in large organisations who have taken all the right steps in moving to agile but are still having trouble motivating their teams, and the missing piece is almost always being exposed directly to your users. Whether they’re end customers, or internal users, there’s nothing like seeing people use your products to motivate the team to make them better.

Original source: Lessons from the UK Government’s Digital Transformation Journey

Link: Post-Authenticity and the Ironic Truths of Meme Culture

‘What is changing, I argue, are the cultural formats people are using for discussion — the carrier waves for this signal. This is where “authenticity” isn’t a useful claim any more, having been wholly co-opted and commodified into its opposite. Culture and the way we communicate — shaped by media affordances — have become more complex, ironic, and multi-layered than that.

‘It turns out, even people who share fake news stories are trying to tell a kind of truth too.’
Original source: Post-Authenticity and the Ironic Truths of Meme Culture

Link: Post-Authenticity and the Ironic Truths of Meme Culture

‘What is changing, I argue, are the cultural formats people are using for discussion — the carrier waves for this signal. This is where “authenticity” isn’t a useful claim any more, having been wholly co-opted and commodified into its opposite. Culture and the way we communicate — shaped by media affordances — have become more complex, ironic, and multi-layered than that.

‘It turns out, even people who share fake news stories are trying to tell a kind of truth too.’
Original source: Post-Authenticity and the Ironic Truths of Meme Culture

Link: Explaining the problems in The Last Jedi

“It is a movie about knowing what’s right and doing that, even though everything else in the universe is stacked against you. It is a movie about why you might start a rebellion against a fascistic order, rather than simply going along with the status quo. Part of the movie is about how the worst people in the universe aren’t even the First Order, but the rich profiteers who are happy to go along with whoever’s in power, so long as they keep making a few bucks…. The theme of The Last Jedi, then, is about being tested, about having everything you value thrown into question and figuring out for yourself the right thing to do. You can’t make the world perfectly safe for your metaphorical children. You will fail them, and they will fail you.”

Seemed like a good movie to me.
Link to original

Link: How Culture Affects Depression

“[B]y virtue of prioritizing emotions and personal happiness, in contexts like the U.S., we are creating a discrepancy between how we feel and how we are supposed to feel… In western societies, we don’t see enough adaptive strategies like reappraisal: learning to tell yourself a different story that would eventually lead to different emotions.”

Link to original

We’re getting exactly the government IT we asked for

If there’s one complaint that I hear consistently in my studies of IT in large organizations, it’s that government IT, as traditionally practiced, is fucked. Compared to the private sector, the amount of paperwork, the role of contractors, and the seeming separation between doing a good job and working software drives all sorts of angst and failure.

Mark Schwartz’s book on figuring out “business value” in IT is turning out to be pretty amazing and refreshing, especially on the topic of government IT. He’s put together one of the better “these aren’t the Droids you’re looking for” responses to ROI for IT.

You know that answer: you just want to figure out the business case, ROI, or whatever numbers driven thing, and all the DevOps-heads are like “doo, doo, doo-doo – driving through a tunnel, can’t hear you!” and then they pelt you with Goldratt and Deming books, blended in with some O’Reilly books and The Phoenix Project. “Also, you’re argument is invalid, because reasons.”

A Zen-like calm comes over them, they close their eyes and breath in, and then start repeating a mantra like some cowl-bedecked character in a Lovecraft story: “survival is not mandatory. Survival is not mandatory. Survival is not mandatory!”

Real helpful, that lot. I kid, I jest. The point of their maniacally confusing non-answers is, accurately, that your base assumptions about most everything are wrong, so before we can even approach something as precise as ROI, we need to really re-think what you’re doing. (And also, you do a lot of dumb shit, so let’s work on that.)

But you know, no one wants to hear they’re broken in the first therapy session. So you have to throw out some beguiling, mind-altering, Lemarchand’s boxes to change the state of things and make sure they come to the next appointment.

Works as Designed

Anyhow, back to Schwartz’s book. I’ll hopefully write a longer book review over at The New Stack when I’m done with it, but this one passage is an excellent representation of what motivates the book pelters and also a good unmasking of why things are the way we they are…because we asked for them to be so:

The US government is based on a system of “checks and balances”—in other words, a system of distrust. The great freedom enjoyed by the press, especially in reporting on the actions of the government, is another indication of the public’s lack of trust in the government. As a result, you find that the government places a high value on transparency. While companies can keep secrets, government is accountable to the public and must disclose its actions and decisions. There is a business need for continued demonstrations of trustworthiness, or we might as well say a business value assigned to demonstrating trustworthiness. You find that the government is always in the public eye—the press is always reporting on government actions, and the public is quick to outrage. Government agencies, therefore, place a business value on “optics”—how something appears to the observant public. In an oversight environment that is quick to assign blame, government is highly risk averse (i.e., it places high business value on things that mitigate risk).

And then summarized as:

…the compliance requirements are not an obstacle, but rather an expression of a deeper business need that the team must still address.

Which is to say: you wanted this, and so I am giving it to you.

The Agile Bureaucracy

The word “bureaucracy” is something like the word “legacy.” You only describe something as legacy software when you don’t like the software. Otherwise, you just call it your software. Similarly, as Schwartz outlines, agile (and all software processes) are insanely bureaucratic, full of rules, norms, and other “governance.” We just happen to like all those rules, so we don’t think of them as bureaucracy. As he writes:

While disavowing rules, the Agile community is actually full of them. This is understandable, because rules are a way of bringing what is considered best practices into everyday processes. What would happen if we made exceptions to our rules—for instance, if we entertained the request: “John wants to head out for a beer now, instead of fixing the problem that he just introduced into the build?” If we applied the rules capriciously or based on our feelings, they would lose some of their effectiveness, right? That is precisely what we mean by sine ira et studio in bureaucracy. Mike Cohn, for example, tells us that “improving technical practices is not optional.”15 The phrase not optional sounds like another way of saying that the rule is to be applied “without anger or bias.” Mary Poppendieck, coauthor of the canonical works on Lean software development, uses curiously similar language in her introduction to Greg Smith and Ahmed Sidky’s book on adopting Agile practices: “The technical practices that Agile brings to the table—short iterations, test-first development, continuous integration—are not optional.” I’ve already mentioned Schwaber and Sutherland’s dictum that “the Development Team isn’t allowed to act on what anyone else [other than the product owner] says.”17 Please don’t hate me for this, Mike, Mary, Ken, and Jeff, but that is the voice of the command-and-control bureaucrat. “Not optional,” “not allowed,” – I don’t know about you, but these phrases make me think of No Parking and Curb Your Dog signs.

These are the kind of thought-trains that only ever evoke “well, of course my intention wasn’t the awful!” from the other side. It’s like with the ITIL and the NRA, gun-nut people: their goal wasn’t to put in place a thought-technology that harmed people, far from it.

Gentled nestled in his wry tone and style (which you can image I love), you can feel some hidden hair pulling about the unintended consequences of Agile confidence and decrees. I mean, the dude is the CIO of a massive government agency, so he be throwing process optimism against brick walls daily and too late into the night.

Learning bureaucracies

The cure, as ever, is to not only to be smart and introspective, but to make evolution and change part of your bureaucracy:

Rules become set in stone and can’t change with circumstances. Rigidity discourages innovation. Rules themselves come to seem arbitrary and capricious. Their original purpose gets lost and the rules become goals rather than instruments. Bureaucracies can become demoralizing for their employees.

So, you know, make sure you allow for change. It’s probably good to have some rules and governance around that too.

Often, people just won’t change, or, there is no magic to thaw the frozen mind

Under the auspices of “how can we DevOps around here?” I’ve had numerous conversations with organizations who feel like they can’t get their people to change over to the practices and mind-set that leads to doing better software. The DevOps community has spent a lot of time trying to gently bring along and even brain-hack resistant people and there are numerous anecdotes and studies that doing things in DevOps/cloud native/agile/etc. way not only make businesses run more smoothy and profitably, but make the actual lives of staff better (interested in leaving work at 5pm and not working on weekends?)

Still, for whatever reasons, the idea of “the frozen-middle” is reoccurring. In government work, there’s often the frozen-ground” with staff throwing down their heels as well.

Most of the chatter on this topic is at the team level, and usually teams in already flexible, new organizations (like all those logos on scare-slides in presentations from people like Pivotal: UBER! AIRBNB! TESLA! SOFTWARE-IS-EATING-THE-WORLD, INC.!) If you’re already in a company that can change its culture every year, the pain of these “frozen” people is almost nil in comparison to being in government, a 50-100 years old company, or otherwise “in the real world.”

Right here, I’m supposed to establish empathy with these frozen people to get them to change. I should stop calling them “frozen people” and treating them like “resources,” and think of them as people. That is all true, but what do I do after I’ve cavorted with them in empathy splash-pads for months on end and we still can’t get them to configure the firewall so we can do the DevOps? What do you do with enterprise architects who have become specialists in telling you how impossibly fucked up everything is? How do you work with all those “frozen middle-managers” who are acting as a “shit umbrella” (or maybe in this case, a “rainbow umbrella”?) to all your fanciful DevOps notions?

There’s one last ditch tactic: money and firing. When it comes to changing the culture in a large orginizations, this is the big hammer that upper-level management has. That is, the middle-manager’s manger is the one who has to tools to fix the problem. By design, the surest, easiest, sanctioned way to change behavior is to change cash pay-outs and other compensation based on not only the performance of people (management and staff), but their willingness to adapt and change to new, better ways of operating. That is: you reward and punish people based on them doing what you told them to do, or not.

There’s all sorts of “little and cheap” things to do instead of bringing out the big hammer:

  • Giving out acrylic trophies, showering people in attention from high-level execs
  • Fame and glory internally and externally
  • T-shirts (no, really! They work amazingly well)
  • Sanctioning goofing off (“we may have a 15 day holiday policy, but, you know, you should leave work at 4 every day and don’t log vacation”)

Matt Curry covers most of these management-hacks in a great talk on changing large organizations. But let’s assume those aren’t working.

At this point, “leadership” (middle-management’s management) needs to reward and punish the unfreezing or freezing. If middle-management changes (“unfreezes”), they get paid more. If they don’t unfreeze at least their pay needs to freeze, and at “best” they need to get quarantined or fired (as a tone-note, back when I was young and the idea of getting “laid-off” or “RIFed” started being used I reprogrammed myself to only ever say “fired” in reference to loosing your job: those soft, BS words obscure the fact that you’ve been, well, fired – so, feel free to s/// whatever more HR-correct phrase you like into there).

If you look at the patterns of change in most companies going cloud native, they do exactly this. Organizations that successful change so that they can start doing software better set up separate “labs” where the “digital transformation” happens. These are often logically and physically separate: they often have new names and are often “off-site” or well hidden, in the skunk-works style. They do this because if they stay mentally and physically in the “old” system, they end up getting frozen simply due to proximity. The long-term, managerial strategy, here, is an application of the strangler pattern to the “legacy” organization: eventually, the new “labs” organization, through value to the business and sheer size, becomes the “normal” organization.

The staff process they use – almost as a side-effect! – is to only move over people who are willing to change. I’d argue that “skills” and aptitude have little to do with the selection of people: any person in IT can learn new ways of typing and right clicking if the company trains them and helps them. We’re all smart, here.

What happens is that you cull the frozen people, either leaving them behind in the old organization (where there’s likely plenty of work to be done keeping the legacy systems alive!), or just outright firing them. That’s all brutal and not in the rainbows and sandals spirit of DevOps, but it’s what I see happening out there to successfully change the fate of large organizations’ IT departments.

You don’t really hear about this in cheery keynotes at conferences, but at dark bars and (I shit you not) in quiet parking garages I’ve talked with several executives who paint out this unfreezing-by-attrition process as something that’s worked in their organization. One of them even said “we should have gotten rid of more people.”

This pattern gets more difficult in highly labor-regulated industries – like government work and government contractors – but setting up brand new organizations to shed the frozen old ways is at least something to try.

And, barring all else, as I like to say, if nothing is working, and people won’t actually change, Pivotal is always hiring.

If that’s too grim, don’t despair! My buddies have a much light-hearted, hopefully whack at the problem in a recent discussion of ours:

How Muslims Defined American ‘Cool’

“‘Hotel, motel, Holiday Inn’ is not exactly a revolutionary mantra.”

Tracking that line through hip-hop songs is awesome fun. Also, this piece is an important reminder of how huge parts of American culture are evolved and defined, and how much we take them for granted as being “mainstream” once they, well, become mainstream.

Link

“It was just dumb”

This a good parable on what can go wrong in large organizations when incentives are not working as planned.:

But the reality seems to be messier and more boring: Wells Fargo wanted its employees to push lots of real accounts, it asked too much of them, and the employees rebelled by opening fake accounts to get the bosses off their backs. The fake accounts weren’t profitable for Wells Fargo, and no rational executive would have wanted them, which is why Wells Fargo kept telling the employees not to open them. But the employees did anyway because they felt like they had no other choice. It was not an evil high-level plot. It was just dumb. It was a form of employee resistance that was channeled into fraud by bad incentives and bad management. There is a limit on how many times you can ask a guy in a hearing “this thing you did was pretty dumb, wasn’t it?” Though look for the Senate Banking Committee to test that limit.

Knowing very little about the details, back in IT-land problems like this usually mean the culture needs some tweaking.

Check out some more commentary.

Improving IT recruiting by rethinking IT priorities

Allstate people working

Most people seem to have complaints about hiring IT staff. They can’t find the right skills, or just people. Of course, what little economics I know would suggest that this means the price (wages) should be higher.

Also, there’s probably a need a rejigger how organization’s think about IT, namely by dividing projects up into low-value (non-differentiating), and high value/differentiating buckets. Those answers are all too simple, really. The question is how to get the IT department to the point where management can do those things.

Jon Reed summerize a and comments on an article on this topic:
Continue reading “Improving IT recruiting by rethinking IT priorities”