Catalysts and Psychological Safety

Catalysts are important not only in chemistry

In the timeless classic Peopleware, the authors tell the anecdote of an employee who was, at first glance, not visibly standing out in terms of any particular ability. One thing was striking, though: Projects she was involved in had a significant higher chance of being successful than projects she was not a part of. The secret? Tom DeMarco writes: […]

The Horowitz-Buckingham Leadership Argument

There has been a lot of discussion lately about Steve Blank’s article in which he argues that Tim Cook leading Apple is comparable to Steve Ballmer leading Microsoft: Both followed after iconic visionaries - Steve Jobs and Bill Gates, respectively - who embodied the company like no one else. Both were able to increase revenue and profit numbers at an impressive scale. However, both also failed to stimulate and harness the innovative powers within their respective company, and relied mainly on their strong brand for several years. […]

Recognizing a Training Dead End

Not all training is equally effective

Do you remember Math in school? If you were good at it, did you help others when they were struggling? Did you always succeed? I remember that I did not. There were these recurring situations that left me clueless on how to make my point, and how to get my tutee to understand. For example, I would try to explain to a friend how to solve a simple equation with X as an unknown. This would go something like this […]

On Being Surpassed Gracefully

When you become an engineering manager, others might surpass you technically

Who do you think will be able to run faster after a year of training, given that both have similar physical abilities: Somebody practising eight hours a day, or somebody practising two hours a day? Most likely, it will be the one practising eight hours a day. A similar logic applies with technical skills, and this logic becomes very real when you transition from an engineering or tech lead position into a management position. […]

Avoid Shuttle Diplomacy

Don't be a shuttle

I am a middle child, with an older brother and a younger sister. My brother was pretty jealous of me when we were little, so, in order to avoid triggering his jealousy, I learnt early on to care about his interests, sometimes as if they were my own. When my sister entered the scene, this tendency was even intensified. She was the first girl in the family, and under "special parental protection" - meaning that if she was unhappy, one of her brothers was likely to be identified as the culprit. Better keep her happy, then... […]

Giving Feedback Without Much Context

Situation: I noticed that one team had almost no discussions around their code changes before they were merged. Other teams did. They would make suggestions for improvement, point out flaws, and sometimes do several rounds of commenting and re-committing before code was actually merged. This was the point of code reviews, after all. […]

What is Your Territory?

Your territory is where you build up mastery

One of the most interesting things I took away from The War of Art by Steven Pressfield is the distinction between territory and hierarchy. Pressfield introduces the concepts as follows: […]

A Competition of Goals?

Which goals do employees really pursue?

Earlier this year, I was told about a discussion among higher-ups at a tech company. There had been a survey among all employees, and the result was that many of them were dissatisfied with the lack of perspective they saw in terms of personal advancement and development. There were no career tracks, nor were there personal development plans of any sort. A higher-up manager reacted to these concerns in a very particular way. […]

Organizational Teaching

When I was about to finish this post, I discovered Why Startups Should Train Their People by Ben Horowitz, which was written in 2010 and covers most of what I am writing below, plus some additional points. If you have time only for one of the two, I advise you to go and read that. […]

Refactoring For Non-Coders

Learn how to refactor a house!

In a previous post, I tried to provide an analogy to help non-technical people understand why the number of produced lines of code (LOC) is not a good measure of developers’ productivity. While there may be a demand for such an analogy, the demand is probably even higher for an analogy for refactoring. I sometimes view refactoring as the eternal apple of discord between developers and stakeholders (and I am not saying developers are always right to refactor). The need to refactor is not always immediately clear to management or other stakeholders, and, if they have never seen a large codebase from the inside, who could blame them? […]