# Socratic questioning

First, the method and it's good intentions:

Socratic questioning—Here, you leave people to draw their own conclusions by simply asking a set of helpful questions to take them to the realization that there’s an issue (and the hope is that they’ll then ask you for a solution or even stumble on your solution and offer it up as if it were their own). This, we’re told, increases ownership of the issue because the other person—the person needing to change—came up with the idea himself.

Then, how it often doesn't work out as exploration, more as pointing to an existing point:

Socratic questioning—This one is trickier, because it often looks open and curious. You’re asking questions, so aren’t you already doing what this different-questions approach suggests? Our experience is that generally people who use this approach are not actually curious about something new they might learn from the other person. (This lack of curiosity starts, we’re sorry to point out, with the great Socrates himself, who was a smart fellow who might be forgiven for thinking he had the solution concealed inside his cloak.) Instead, the questioner leads the person down a familiar path (designed by the questioner) and entirely inside familiar (to the questioner) territory. We can spot this in our videos with leaders because they will generally ignore any new information that comes their way and continue their set of questions. When someone gives an unexpected answer to the question, the leader looks more exasperated than confused—because the other person is missing the point. The leader is using questions to search for particular answers, not to get more information on the table.

I always want Socrates to just tell me what he wants the conclusion to be and work backwards. Plato needed an editor, perhaps. But chopped down, Socrates proofs wouldn't have seemed proofs.

Both quotes from Simple Habits for Complex Times.

Finishing books is overrated

They are often very pretty to look at. You also feel you can read them in small bites, or you can read only a single chapter or section. The compulsion to finish is relatively weak, a good thing. You can feel you have consumed them without reading them at all, a true liberation, which in turns means you will read them as you wish to.

Tyler here is one the biggest proponents of not finishing books if you don’t find it valuable. This notion is so different than the usual upbringing, what I’ve had, at least. It also raises concerns of FOMO, and lost money in those pages not read. I think it would work best with physical books: it’s still very hard to scan and flip pages in Kindles (perhaps a skill I need to build).

Original source: In praise of art books

Intuit developers’ experience using kubernetes

It’s not quite at the level we would like. For example, if services have a hiccup or a Kubernetes pod goes down, developers still need the level of knowledge to look at the logging and understand what happened. But they don’t need to understand how to manage clusters or namespaces, they don’t have to deal with auto-scaling.

Some good stuff in there. There's also a looming paradox: we don't want developers to know about Infraestructure, but they need to.

Original source: Q&A: Intuit's Developer Experience with Kubernetes

Analysis of Koch buying Infor

While Infor is widely considered to be the third largest ERP vendor, with a 5 percent to 6 percent share of the ERP market (according to Gartner and IDC, respectively), the company is not a serious challenger to ERP heavyweights Oracle and SAP, which reported fiscal 2019 revenues of $39.5 billion and €27.5 billion (about $30.1 billion), respectively. Infor reported $3.2 billion in revenue for fiscal 2019, which was just 3.0 percent higher than the prior year, according to Infor’s fiscal 2019 results (the company was not required to disclose financials, but did so anyway, ostensibly to build goodwill among prospective investors who value clarity in corporate governance). Over a decade ago, the company touted in excess of 70,000 customers. Today, that number is 68,000, despite continued acquisitions.

And:

Koch Industries has invested more than $26 billion in technology-related investments over the past six years

Original source: Why Koch Is Buying the Rest of Infor

Media tools, not social media

Here’s the thing though as part of the unlearning process I’m currently going through. As a starting point, the social tools are everything, but social nowadays. I, for instance, stopped calling these tools social media a few years back and instead decided to stick around with just media tools.

Because that’s what we’ve decided to convert them to over time. A series of manipulative online tools that allow us to toot our own horn about how good and well crafted our own selling and marketing messages are. We have decided to stop listening altogether. Instead, we’ve now become the product we’d want to sell to others, and, as a result, decided to stop conversing with those who we once called our own social networks or community spaces where conversations were the new currency.

Original source: Unlearning

Warm handoffs from the community

“Any of the tasks that DevRel should be doing need to be directly tracked back to the corporate goals,” Thengvall said.

She argues every DevRel person should be leveraging customer resource management software (CRM) to track all that she previously dubbed “warm hand-offs.”

Thengvall says a CRM helps support a mix of measurability and owning your community — instead of risking them just getting dumped into the newsletter list. These “DevRel qualified leads” are owned by the developer advocate, who then makes introductions. Does someone have a great use case? Introduce them to marketing to produce a blog post. Somebody giving really solid feedback? Intro them to the product team as a beta tester. Someone really enthusiastic about your product and great at coding? An intro to HR may be in order.

Original source: Measuring the Value of Developer Relations

Reading 5 hours a day, and other tips on reading more

Stephen King had advised people to read something like five hours a day. My friend said, “You know, that’s baloney. Who can do that?” But then, years later, he found himself in Maine on vacation. He was waiting in line outside a movie theater with his girlfriend, and who should be waiting in front of him? Stephen King! His nose was in a book the whole time in line. When they got into the theater, Stephen King was still reading as the lights dimmed. When the lights came up, he pulled his book open right away. He even read as he was leaving. Now, I have not confirmed this story with Stephen King. But I think the message this story imparts is an important one. Basically, you can read a lot more. There are minutes hidden in all the corners of the day, and they add up to a lot of minutes.

Original source: 8 Ways to Read (a Lot) More Books

Being friends with someone makes it hard to write op-ed’s about them.

I write about tech executives, and (no joke) refuse to meet with them. Mostly because I’m an introvert and don’t enjoy meeting new people. But also because intimacy is a function of contact. Often when I meet someone, I like them as a person, feel empathy for them, and find it harder to be objective about their actions.

Original source: IOWAt the fu*k?

Smaller procurement cycles help eliminate waterfall badness in government IT

Big contracts don’t set the government up for success. Agencies invest millions of dollars without the ability to test the vendor and the technology. Multiyear contracts allow few options for agile pivoting, in case something doesn’t work out and the mission needs to change directions.

Smaller procurements are more flexible and agile, and they also allow for increased competition, which leads to better solutions that are more impactful for government agencies. In addition, when contracts are narrow at a smaller scale, it diminishes the risk of a vendor protesting, which stops the entire project and pulls you into court. Thoughtfully planning smaller procurements can save the protest headache that will suck time and money away from your mission into a wearying process with a side effect of unsavory headlines.

Original source: To Modernize, Push for Smaller Procurements

IBM’s financials for the past 8 years

Also, commentary on product strategy missteps, good ideas that didn’t turn out to be viable, and, thus, out to be the wrong focus.

Most IBM doubters also skip of the structural problems inherited from the previous “decade,” but Charles outlines it well:

Rometty didn’t inherit a great hand. Her predecessor Sam Palmasaino hollowed IBM out and turned it into a financial engineering company as opposed to an engineering engineering company. Palmasaino focused the company on an EPS roadmap instead of a product roadmap.

‪Focusing on “an EPS roadmap instead of a product roadmap.” That’s good. While “regular” enterprises try desperately to become tech companies, large tech companies face often struggle to stay tech company. Strategy is becomes even more important for both.‬

Original source: IBM’s Lost Decade

The history of Microsoft Azure.

In a famous internal Microsoft memo dated October 28, 2005, Ozzie articulated his vision for building a disruptive platform that would replicate the design of Microsoft Windows OS, .NET application services and Microsoft Office Suite on the Internet. Little was known that this idea would eventually translate into Azure IaaS, Azure PaaS and Office 365.

Original source: A Look Back At Ten Years Of Microsoft Azure

Should I do microservices?

One common architectural driver discussed when comparing a modular monolith with a microservices architecture is level of complexity. Grzybek finds the modular monolith less complex than that of a distributed system. High complexity reduces maintainability, readability and observability. It also requires a more experienced team, an advanced infrastructure, and a specific organizational culture. If simplicity is a key architectural driver, he therefore strongly recommends a team to first consider a monolith

The hot new trend is to apply Betteridge's law to the question of microservices. Beats me, man.

Original source: Modular Monolithic Architecture, Microservices and Architectural Drivers