Category Archives: Management

What Kind of Job is Right for You?

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 it. The first is gradual improvement, and I suspect this 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 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

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?

Simon Sinek: The Finite and Infinite Games of Leadership

Another very interesting talk of Simon Sinek, this time at Google. The full title is

“The Finite and Infinite Games of Leadership: Leadership, Business and Finding Purpose in the Workplace.”

The following points were interesting  for me:

  • Time code 7:00 :  Infinite players do not compete with the competition but themselves. This has an awful lot of strategic implications.
  • Time code 16:55 : Dealing with personal objectives and bonuses. Also see my post about this very topic.
  • Time code 33:00 : Why are small companies usually more innovative than big ones?

Structure of Development Teams

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

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.

You are not faster with an 80% solution

When the schedule is tight for a software development project, one of the first things non-technical people contemplate, is reducing quality and/or scope and go for an 80% solution. This can work but only under particular circumstances.

A recent discussion I had with some folks was about such a situation. A very tight deadline had been issued by senior management and multiple departments had to collaborate on a solution that spawned multiple parts of the organizations and their core IT systems. Those systems (think about something like ERP and CRM) have a multitude of connections, grown over many years without governance, but not for the data that were required now.

The people were all quite supportive and a constructive discussion took off. Not surprisingly, finding a common language took some time. Especially so because only after a while did we realize that in several cases the same term had a different meaning. In the end there was a particular detail where no obvious solution was available.

I was responsible for the technical implementation on one of the two systems involved. My counterpart on the business side and I discussed various options and and eventually he came up with the idea to just safe time by going for the 80% solution. We talked about a number of aspects and it soon became clear to me that this would actually require more time than to just “do it properly”.

This sounds, at the very least, counter-intuitive for most people. So let me illustrate my point with a non-technical equivalent. Many years ago I had to prepare for my then-boss a list with press clippings every day. It basically meant to go through a long list, that was created automatically, and remove everything he was not interested in. This was quite time-consuming and he was genuinely surprised when he found out.

His statement then was “Why do you need so much time, it is only 20 of the 200 articles that are relevant”. That was of course correct. But what he had not thought about was that I had to go through the list of all 200 articles and check some in more detail than just looking at the headline. So it did not really make a difference whether I cut the list down to 100 or 60 or 20 articles, the time required stayed more or less the same. He agreed on the point and quite soon decided there was better use for my time.

It is exactly the same with taking shortcuts during a technical implementation. The easy part is to decide that you want to cut 20% off the next release. But things get tricky when it comes to deciding which 20% to skip without any undesired side-effects. In order to be able to do that, you need to understand in depth what the consequences would be. So quite often you spend more time trying to understand potential ramifications for various scenarios, than it would take to simply do it properly right from the start.

And that is only the beginning of the problem. You need to document the results of your analysis really carefully, if you want to be sure that nothing is missed when the first code change is required. Even a seemingly minor bug fix has an increased potential to break something if the current overall solution is built on a set of assumptions. And adding enhancements or new features will be even more “fun”. Because people have to read through all the documentation and also understand it. Together this is a time-consuming task with considerable risk to still overlook something (or hit an edge-case that was not documented).

But in reality this documentation does not exist anyway because you wanted to save time in the first place. And detailed documentation is not exactly supportive here. So people throw in bits and pieces and you end up with a document that is typically even worse than most project documentation that is out there. So whoever has the pleasure to work on the code without having all the details in mind is really screwed. That includes you, by the way, because you will have forgotten most after only a few weeks.

The solution is usually a re-implementation because it is faster than to fix the broken code. Of course that re-implementation often needs additional logic to handle data migration for transactions that were completed with the 80% solution and now ruin your data quality. But hang on, that might just be 20% effort you can safe right now ….