Category Archives: Career

Don’t Promote for Performance

Career, Management

Quite recently I heard a fascinating statement (Simon Sinek, again 🙂 ) about how the US Navy SEALs select people for promotion. It boils down to “trust over performance”. Allegedly, if they need to decide between someone who is a high performer that people do not really trust, and someone who is a mid to low performer that people trust, the latter wins.

The reason is the effect that someone not trusted will have on the organization. That person (and/or the promotion choice) will instill distrust with all its consequences into people. From my own experience I can only support that argument. Haven’t we all had that boss who made it clear from day one that only their own success mattered to them?

If we look at most commercial organizations, however, what is the reality there? Yes, performance is the only(!) thing that counts – and mostly it is short-term performance, which makes things even worse. It is really sad, and I have a hard time getting my head around it. Yes, in a way I am an idealist. But I think that I have been having a good-enough career to not be seen as out of touch with reality altogether. It is more that I increasingly think that corporate success happens not because of its management, but despite it.

I guess my thinking is also influenced by having had my own company while studying at university. The only thing that counted for me at the time was customer satisfaction. So, as I still like to say, after the deal is before the deal. The hit-and-run mentality sometimes seen in larger organizations is something I always thought to be, quite frankly, galactically stupid.

The good thing, though, is that things seem to starting changing gradually. Let’s support this and all have a better live. Oh, and one last thought: Why is it that senior managers, soon after having joined a new employer, bring on board people they know from before? Because they trust them.

Understanding the Problem

Career, Management, Smalltalk

In recent weeks I have come across a number of readings and videos, which brought forward something that, in hindsight, had been nagging me for a very long time. Unfortunately I cannot provide a list of said material, because it has all happened subconsciously and only just “erupted” a few minutes before I started writing this.

The subject in question is the relevance of understanding a given problem for determining a solution. This sounds totally obvious if not even a bit silly, I admit. How would anyone be able to work on a problem that is not understood? But it becomes less silly if we re-phrase things a little bit.

So far the wording implied a somewhat binary view: Either the problem is understood or not. But in reality very little is truly binary. So instead we could say that the level of understanding of a problem is the primary driver for the outcome of the attempt to solve it. Admittedly, this still sounds pretty obvious.

The next stage in dissecting would be to say that a problem needs to be understood well enough to find a sufficient solution. And here it starts getting interesting, since we basically have an equation with two variables.

The first is about being “sufficient”. Because of resource constraints most problems will be approached with the aim to apply only a “just good enough” solution. In my profession (software engineering) this usually means a quick fix rather than a clean approach with refactoring and all the other good stuff.

What I personally consider more impactful, though, is the “well enough”. Most people I have met so far, do happily go for the first explanation of a problem and consider it a sufficient basis for determining how it should be approached. But in many cases this means only that the symptom has been identified correctly. Neither has the direct cause for the symptom been found, nor the root cause. I see several reasons why people jump onto the “obvious” reason so eagerly rather than to dig in.

  • Different layers: Like in medicine the symptom, the direct cause, the indirect cause(s), and the root cause can be in different “hemispheres”. In business this could be customer churn, caused by bad customer support, caused by a missing link in a process, caused by misalignment of two separate organizational units, caused by personal animosity between their bosses.
  • Motivation and personal objectives: Unless people have a mind that genuinely strives for perfectionism, they will factor in their personal objectives to determine how much energy to put into something. And in most cases this simply means to invest as little effort as possible.
  • Importance not considered high enough: While the personal objectives point above is, at its core, about a selfish decision to optimize personal gain, this is about a perceived objective lack of importance. If I genuinely believe that something is more or less irrelevant, why would I bother (irrespective of personal gain)?
  • Happiness to have found anything: This is basically about impulse control. Rather than exert self-control and think about whether or not there might be other and/or additional aspects, people simply jump onto the first thing that comes their way.
  • Lack of knowledge: The difference to the happiness point is purely the motivation. While the result is the same, the reason here is sheer necessity, since people do not know enough on the subject. So they are just glad to have come up with something at all.

When you follow the line of argument, you will have the fundamental reason why larger organizations so often struggle to even solve the simplest challenges in a proper way. Instead you will mostly see a myriad of changes that are applied, at best, with local optimization in mind. The latter, unfortunately, means that you are almost always moving further away from a global optimum. What good is it for a company if one department improves the financial bottom line of the current quarter at the expense of disgruntled customers that spread the word?

What Kind of Job is Right for You?

Career, Management

I recently came by an interesting article that examined a certain personality aspect and what it means for choice of job. That aspect was the desire to make your own rules in the workplace vs. enjoying to optimize something given. Obviously someone who does not like to work under imposed rules will be better off by starting their own business rather than joining a large organization. So far, so good.

There is, in my view, an additional “angle” to this. Looking deeper into the optimization of existing rules, processes, policies, etc. there are two conceptually different levels to do it. The first is gradual improvement, and I suspect this is what most people think of. It basically means that you do your job and once you have enough experience and the appropriate mindset, you start seeing opportunities where things can be done better.

But where it really starts to get interesting is when we talk about radical changes. A current example is the switch of large parts of the software industry to a subscription-based licensing model. This has implications for an enormous variety of aspects (and their KPIs for that matter). A few examples would be

  • Sales: Strategy, staff training
  • Finance: Treasury, reporting, investor relations
  • R&D: Release planning, product quality
  • Legal: Contracts (number, variance, …)

The problem with the examples above, is that it is a purely functional view. The latter, by definition, creates challenges for processes that cross functional boundaries. And I daresay that most core processes are not confined to a single department these days.

So, coming back to job types, what do I do if I have a really fundamental understanding of the situation and its challenges as well as great ideas how to handle things, but do not like corporate politics? I am certain that those three factors (truly understand the problem, have a sound solution, no politics) are a fairly typical combination.

The reason lies in what kind of jobs people with a certain personality typically choose. The people who are interested in deeply understanding things are usually more on the reserved, and often introverted, side of the spectrum. Also, they typically hate office politics and just want to do a great job on the “content level”.

Coming to a (preliminary?) conclusion this means that in most organizations people have three options and they come down to the old “love it, change it, or leave it”. I can accept office politics as a by-product of a really interesting job and learn to live with them. Most people, I guess, will stay silent and just do their job but more or less quit internally. And a few brave souls will look out for something new.

My Problem with Conventional Wisdom

Career, Management

More and more I have realized over the last few years that I have a really big problem with many positions that are considered “conventional wisdom” or best-practice. And this goes for a wide variety of topics: software development (which I consider my main competency), technology as a whole, management, career planning, strategy, etc.

In the areas where I have developed a high level of expertise it has been clear for the longest time, because there I could easily see what conventional wisdom usually is: An oversimplified version of the true matter, that anybody can talk about assertively after having spent one or two hours with it. It is a bit like at university when after a 90 minute lecture some people really think they now understand what normalization in the context of the relational data model means.

But in reality the conventional wisdom is usually the lowest common denominator, and that only for a specific context. If you understand this and take it as a starting point for a real discussion, that is fine. But never fool yourself and think you have understood the topic. Unfortunately, this is a somewhat unpopular position and many people are offended by the mere suggestion that something is more complex than they thought so far.

What makes this a problem is when you combine it with another conventional wisdom: “Any decision is better than no decision.” Really? I think it is downright stupid. Of course, one should avoid what is called analysis paralysis and define a threshold for when a decision needs to be made. But all too often it is just an excuse to make a decision without having the slightest clue what its consequences are. Or to quote Herodotus (484-452 BC): “Quidquid agis prudenter agas et respice finem” – whatever you do, do it wisely and consider the end.

Back to the actual topic: Assuming that conventional wisdom comes into being roughly the same way for all subjects, this also means that you should stop accepting it for things you don’t know much about. Think of it as a news clip-version of something really complex. It is probably not completely wrong, but certainly an extremely limited version of the true matter. If you want to understand things, you need to dig deeper.

When looking at this from a strategic point of view, conventional wisdom in many cases means the same as commodity. If you are a product company (and that includes software) going for what everybody else does, will not help. Rather, you should spend some time thinking what you want to do really well. Believe me, it is not convincing when you interview four vendors and they all tell you more or less the same. All you know after such talks is that none of them really has a grasp of the business they are in.

Conventional wisdom will allow you to play it safe in terms of office politics, but not in terms of market success. Is that what you want?

Job Interview Question: What is Your Favorite Algorithm?

Architecture, Career, Video

While watching the video below, I was intrigued, when this interview questions was discussed (timestamp 56:30-57:35).

It made me think about my response, had I ever been asked the same. And it did not take too long before the answer was clear: the B-Tree. There is a very good section on it in Martin Kleppmann‘s book “Designing Data-Intensive Applications“. And I highly recommend this book anyway.

But as a starting point on B-Trees the following video is also quite helpful:

Structure of Development Teams

Architecture, Career, Management

I just came across another interesting statement about the size of development teams:

The good systems that are presently working were written by small groups. More than twenty programmers working on a project is usually disastrous.
 

What makes this so interesting is its origin. It was said in 1968 during the famous NATO Conference on Software Engineering. Fifty years later I think this is still remarkably true. But why?

In my post on the size of development teams I was aiming at complexity and scope as drivers. The interesting question, though, is whether there are additional points to consider. Having worked pretty closely with some other projects in the meantime, I came across another influencing factor: availability of qualified staff.

You can look at this in several ways. The first hurdle is obviously to have enough developers with the required experience at your disposal. The second is how to allocate their capacity to the portfolio of activities you run. Or put differently: How do you deal with the shortage of know-how you face? Because, let’s be honest, there is always more demand for highly skilled developers than can be supplied. (I am having a déjà vu with my “beloved” macro economics lecture 😉 back in 1996.)

If your organization is above a certain size, chances are that overall a sufficient numbers of good people work there. Does that put you in a better position than some poor fellow working for a small company? Not really. Because your project competes for these folks with all the other work within the organization. And what is the difference compared to competition with an external market? Yes, if you have really good connections to higher management, you can escalate things and possibly get additional people. But you will also burn bridges in the process, which is usually too high a price.

So instead you probably end up with the usual mix of folks: Very few rock stars, many middle-of-the-road folks, some promising newbies, and the occasional looser that nobody wants. Can you deliver something really great with such a mix? It will be difficult in a typical corporate setup where you have to somehow involve everybody. And this involvement of the less qualified half of people will slow down the “upper” half.

It is a very delicate subject and there are many fine lines, some from a legal perspective and many more from decency-to-others point of view. Also, the organization needs to think about tomorrow and therefore must have a “funnel” of to-be-rockstars, which need the best training they can get. And the latter is always working on a difficult project with experts and learn from them. But what few organizations do, is look at competence levels in detail and factor them in.

In other words: You can learn a lot from someone who is one, two, or perhaps three levels above you. But if someone is ten years ahead of what you currently know, the difference is just too big. You will only grasp a small fraction of what they teach you, and even that with a considerable risk of misunderstandings. And they honestly cannot understand why you are not following their great advice. Mutual frustration and dislike are usually the result.

Whether you take competence levels into account or not, considerable effort needs to be spent on non-development activities. If you have a taste for management and leading people that will be a great opportunity for you. But if your primary concern is getting something great and possibly visionary delivered, you should seriously consider a totally different approach: an underground project.

Flying under the radar can really be liberating. This must not be confused with idling around or working on some obscure pet project. It is truly about delivering what the organization needs but cannot accommodate in its own structure. Of course you should be certain that your boss will not fire you, if he or she finds out. But as you probably already guessed, driving an underground project does not mean that you are freed from politics, lobbying etc. On the contrary! You must prepare upfront quite carefully how you counter resistance or outright attacks. And yes, you are running a personal risk. But there is no reward without risk.

Why Companies Fail on Technical Careers

Career, Management

I cannot say how often I read in some company’s image brochure that management and expert career paths are treated equal. There must be companies on our planet where this is true, but I have yet to see it in practice. Why is that? (Unless mentioned otherwise this article is about the IT industry with a strong focus on consulting and software companies.)

In my experience the core reason is a fundamental lack of understanding from the non-technical folks that make the relevant decisions, i.e. management. They have a vague impression of techies that is often dominated by perceived social deficiencies (“They can’t look me in the eye”). While the latter is sometimes true, how can it be a measure of someone’s qualification to perform a complex technical task? And perhaps there is actually a good reason for averting my eyes. I cannot speak for others, but when I have a complicated discussion, it helps me focus all my mental capacity on the problem at hand when I look onto the table.

I would speculate that, as in so may other cases, the heart of the problem lies with mid-level management (where the details are determined) as opposed to the C-level. Taking into account the Peter principle, what does that say about middle management? Yes, this a strong simplification and it does many people injustice. I have personally met quite a few people on this level that I consider great at their job, particularly including leadership skills. But just as well did I encounter folks who cannot think out-of-the-box and blindly follow rules and processes. And it is this capability to see new ways, make realistic projections about what will (not) work, and lead by example “where no-one has gone before”.

A particularly interesting story for me was the encounter with an HR person where we talked about setting up an initiative to advance technical folks (what is often called a high-potential program). My idea was met with friendly resistance and the argument was made that contrary to management, the technical side is so much more diverse that it would be virtually impossible to have a single program. In fact this HR person seriously thought that every techie needed his or her completely individual program.

My counter argument then was that this would not be a technical program (learn programming language XYZ) but one for professional and personal development. So we talk about e.g. how to present a complex technical scenario to upper management for getting a budget approval. Or how to engage with a customer and instill confidence that a given product is the right choice to solve their business problem. And all this with being authentic and building upon the strong technical knowledge one has.

I don’t want to appear as simply bashing HR here. But the underlying problem was that assumptions had been made about what would be suitable for technical folks without ever having spoken with any of them. Would this happen the same way for management staff?

From a more abstract perspective it comes down to the fact that many decisions are made based on personal trust and relationships, rather than on processes and policies. So what is needed is that the relevant management and technical staff (on every hierarchical level) talk to each other in the spirit of equality. And here both sides fail miserably too often.