Type your search keyword, and press enter

About the Author

C. L. Hamer

Read-write-many volumes on LKE with NFS

When deciding whether to use Linode as my kubernetes provider, I needed to ensure that I would have read-write-many volumes available for deployments that need them. So I did a quick search, and the only thing that came up was this guide on setting them up with rook — which is deprecated. Not cool.

On other cloud providers, I created read-write-many volumes using a Network File System — so I wondered if I could do the same on Linode. Answer: yes. And it’s actually pretty easy and works well. Here’s how:

Continue reading “Read-write-many volumes on LKE with NFS”

Let’s Get Real about Disruption

This article is an adaptation of the talk I gave at the EIT Climate KIC Community Summit in Hamburg (July 2019)

Here’s a parable you’ve probably heard:

In the 1890s New York City had a daunting horse manure problem. Transporting people and goods around the city resulted in so much manure that officials worried that the streets would soon be buried deep in it. Apparently in 1898 there was a conference to address the problem in which they essentially gave up.

Continue reading “Let’s Get Real about Disruption”

How and Why to Build your IT Career through Startups

startup_house

I’ve spent most of my career working for tech startups, but I don’t consider myself an entrepreneur. It was kind of by chance that I’ve ended up working more for small and new tech companies rather than big, established ones — and consequently, I’ve learned that choosing this career path offers some real advantages.

If you are an engineer, should you do the same? Let me give you an overview of some of the pros and cons. The short version is the following: It’s more work, more stress, and more varied tasks for less pay — but rising to great challenges means gaining great experience.

Continue reading “How and Why to Build your IT Career through Startups”

Growing from Startup to Scalable: Make the Right Changes at the Right Time

Early in my career I was working for a tech firm that had recently grown from a tiny startup to a company with a few hundred employees. One day the CEO gave a company-wide address in which he explained, “Startups produce code more efficiently than large companies — therefore we will continue to run this company like a startup!”

Unfortunately, in practice, this essentially amounted to free soft-drinks and everyone being expected to work unpaid overtime every day.

I remember at the time thinking, “That’s not how it works. There are reasons a big company can’t function like a startup.” And if you figure in all of startups that fail, it’s not even clear that startups produce more code-in-production per developer than larger companies.

In retrospect, I view that boss’s silly speech as a gift. It has inspired me, as I’ve worked at different companies over the years, to observe carefully the ways that “startup mode” differs from scalable practices — and to think about the best strategies for getting from one to the other.

Continue reading “Growing from Startup to Scalable: Make the Right Changes at the Right Time”

The Perils of Adding Layers of Management

 

If you’re the CEO of a hip, young startup, you naturally want to be the cool, approachable boss — not the one who distances himself from his employees with ten levels of hierarchy by adding a bunch of extra bosses who are just there to tell other people what to do. It’s tempting to dismiss management as a useless task and try to keep your organigram flat forever.

In tech companies in particular, there’s a common misconception that management is “easier” than engineering.

It’s not hard to see where this idea comes from. Typically engineers will spend years getting an advanced degree — or creating an amazing independent project — in order to qualify for a software engineering job. And then someone on the team gets promoted to head the team, usually without any management training of any kind.

But treating management as easier (or as not really a task at all) can lead to some costly errors. I was once on a team where the least-performing engineer got tapped to manage the team. Apparently the idea was that if he’s struggling with coding, maybe he can at least organize the meetings and put the status updates into the project planning software. And that might have worked out if those were the hardest tasks of the job.

Even worse (and more common) is to tap the most productive engineer to be the team lead. The reasoning seems to go like this: “He’s so good at this — he should be telling all of the other engineers what to do,” and/or “With such a brilliant engineering mind, management tasks should be trivial for him!”

Continue reading “The Perils of Adding Layers of Management”

Disruptive Tech Management

disrupt_tech_managementIn our modern tech world, the holy grail is to come up with a new idea or develop new technology that is such a game-changer that it “disrupts” an existing industry. If you want attention, success, and respect in this industry, disruption is the way to go.

But what if you’re in tech management? There’s a temptation to feel like you need to disrupt there too — come up with a game-changing playbook — in order to be on the cutting edge. But while our ever-changing tech landscape naturally leaves doors wide open for new ideas, there’s less reason to imagine that the task of organising a team of engineers to construct something should change dramatically from one decade to the next. So maybe we should consider trying out some old-school ideas.

One of the key components of Scrum and other modern management playbooks is the idea that the team should manage itself. As I explained in my previous article, the tech industry has a huge problem with undervaluing management skills — indeed treating management as though it’s not even a task and doesn’t require skill and expertise. I think the idea of “self-managing teams” is the fruit of that misconception.

If your company needs a custom internal app, you’re not going to make a committee of the accountant, the communications director, and the lawyer, give them a weekend course in design patterns, and tell them to go to it — even if they’re the ones who are going to use the app. You would hire an engineer. Even for a task that requires less specific training than programming an app (say, writing the content of your company’s brochure), you would give that task to someone who is qualified to do it.

Now, if you take a team of engineers — all of whom were hired specifically for their engineering skills — there is no particular reason to believe anyone on that team is qualified to manage it. Chances are that there’s at least one person on the team who is not qualified to be managing other people and projects — so making them all manage together as a committee doesn’t really help. The only way this idea makes any sense is if you believe that management does not require any skills.

Continue reading “Disruptive Tech Management”