Category Archives: Management

Allowing People to Contribute

If you ask organizations what they try to achieve, you will receive responses that all look different. They will typically reference the official purpose of the organization (NGO, car manufacturer, consulting, etc.) and then say what more or less specific goal is to be achieved. But in their essence, what they all strive for is a high performance organization.

To get there an awful lot of things is done: Systems and policies will be put in place, the results analyzed relative to what was expected, and then things will be adjusted because the outcome did not live up to expectations. I am convinced that the core reason for this is simply that the diversity of staff has not been taken into account.

I cannot offer a solution that claims to solve this issue. In fact I am fairly convinced that would again be falling into the trap of ignoring differences – in that case between organizations rather than individuals. But I have come up with an experimental approach that will work for some organizations:

Ask people what they think they can contribute outside their regular function.

You will be surprised to see what your staff has to offer in terms of capabilities and, more importantly, dedication. What you can effectively do with such an activity, is break barriers that a conventional organization puts around creativity. I see many of the traditional organization concepts out there as mechanistic, coming from the era of Taylorism and scientific management. That does not necessarily mean that all of it is unsuitable. But we should certainly apply scrutiny as to whether something is still the right tool for today.

The approach is somewhat similar to an individual curriculum in school. You recognize that people are different, and build upon that. What you achieve, overall, is better performance of the organization. It happens on multiple levels:

  • You foster people’s creativity: See it as a competitive advantage caused by a disruptive model
  • Fewer people will leave the organization: They realize that their current environment is something not to be found in many other places
  • You quickly see who is in for the money (i.e. for themselves only)
  • Boundaries (often called silos) become more open
  • Many people have knowledge and ideas outside their official capacity. That can be harvested to bring fresh wind into other departments without the need to hire external consultants. Those cause demotivation because the team is effectively told that they are not trusted. Also, internal folks need much less ramp-up because they know the organization. (Yes, sometimes you will still need external folks.)

Is this something like a think tank? Yes and no. A think tank, at least in classical terms, is again a typical organization and the concept has been around for a long time. And while part of its job is to provide out-of-the-box thinking, it usually performs that from within a conventional organization.

This approach is not for all people. In fact a large portion of your staff is probably more or less ok with how things are now. The rules give them certainty and boundaries, in which they can operate safely. That is fine and there is a lot of important tasks where this is in fact the only option you have. (Think of accounting and how much of it is regulated by law.)

But as soon as we need to create a competitive advantage, creativity is the only thing that allows an organization to get ahead of others and also stay there. The people needed for this are, for the most part, not motivated by money. They will still ask for a competitive salary, but that is a side factor only. What they demand, though, is an environment of like-minded people and freedom to achieve what they were hired for.

It would be foolish trying to introduce this broadly into an organization that has so far been lead in a more or less conventional way. But you can take the concept of incubators and apply it not on the product level but to organizational development. Reach out to the entire company and ask for teams to apply for a test run. They should develop the details how they want to “run the show” on their own. Some guidance is of course ok, but this will effectively be their first test.

This is the core idea, and likely a lot more detail needs to be figured out before applying this broadly. But I tend to think that it does not help to do this in advance, let alone in a one-size-fits-all way. Each organization (and probably even team) should start their own journey. And letting people figure this out by themselves can only boost creativity and motivation.

Personal Branding

In recent weeks I have come across a number of online articles and posts that covered various aspects of what is now called “personal branding”. Most of them listed relatively specific things to do or avoid. This is something that I think can do quite some damage, when followed blindly. Because at the end of the day you want to convey a picture of what you stand for. So doing or not doing things always needs to be seen in that context.

In my view the purpose of personal branding should be something like an extended version of your resume/CV. The latter is usually oriented towards listing what you did in your professional past and the relevant achievements. What it usually does not show is your personality. Are you a sociable team player or a ruthless egomaniac? Either type could have achieved  what you did (or rather claim to have done). But obviously the side-effects would be very different.

In contrast to the “words-only” description of yourself that a CV basically is, the personal brand should be created by “actions”. I am a big fan of judging people by what they do rather than say. And if someone does charity work in their free time, that tells me a lot about this person. Much more than any impressive job role that is listed in their resume. In this context please also have a look at my post Don’t Promote for Performance.

As a non-marketing person I always had the impression that branding is the most difficult thing in marketing. And while I am writing this it seems very clear to me what the reason is (the marketing people will tell me whether I am in line with conventional wisdom here). The challenge with branding is that a company never can create a brand directly. It can ensure that all the prerequisites are there – like an interesting logo and a catchy phrase. But for those to transform into a brand, the market needs to have a certain perception about them. And that perception is the brand.

The problem with this view is that it explicitly denies the organization direct control of the outcome. You can of course try to raise awareness with expensive advertising campaigns at major international airports. But if nobody ever heard your name, putting it next to a conveyor belt for luggage will not help much. Instead brand creation takes time and continuous effort. And of course you need to support this with traditional campaigns etc.

The actual brand will follow this and gradually develop, as customers are happy and spread the word. And this is also what I recommend to people when it comes to their personal brand: Do good things and “talk” about them. Talking here means every form of communication. Especially technical people, who also tend to be shy and introvert, are often not very good at self-promotion in a direct conversation. But they could give a presentations where their achievements are mentioned. This will not feel like bragging to them, but a more neutral description. And a bit of understatement has rarely hurt in these loud times.

So the bottom line is: Find out what you would like to stand for, deliver great results supporting this, and then spread the word. Sooner or later people will recognize you for it.

Dave Farley: The Problem With Microservices

The definitive video on Microservices, as far as I’m concerned. No marketing bullshit, no misguided “stateless-hello world-crap”, but a concise and applicable set of criteria. It is also worth noting, that overall/in general Dave prefers a service-oriented monolithic architecture. I can’t express how great this video is to describe the real core of the idea of Microservices. Please take the time to watch!

Deciding Where to Lay Off People

I just read a message in the news that a company which, among other things, runs an online job portal for software developers, plans to lay off staff for that portal. The argument made in the news interview, was that this line of business was particularly affected by COVID-19 and to save costs 30 people would be fired. The organization in question, and that is a critical point for this post, has several business lines, and some of the less affected are operating in markets with far less growth potential. Or in other words: they are the core business.

This is a classic example of sacrificing a company’s future and long-term success for some quarterly or yearly goals. Of course there can be situations, which are so extreme that this is the only option. But, frankly, this usually also means that not one but ten things have gone wrong and that also over a longer period of time. So in the majority of cases such an approach is simply an example of what I consider incompetent management.

Let me come back to the reasoning (as per the aforementioned interview) for this job cut. Since when is it a good idea, unless the company is at the brink of bankruptcy, to look primarily (or even only) at the contribution to the financial bottom link for making such decisions. It is in my view at the core of good management to balance the present and future of the organization. And the job market for software developers is certainly something I consider to grow substantially.

I also want to come back shortly to the idea of “core business” and what its properties are. The most important one is certainly financial contribution. But this is more a consequence of a number of underlying properties (think balanced scorecard). In this context the most relevant one is that it is an established business. Or in other words: living off the past. Of course there are exceptions, but for non-startup organizations core business usually means a mature market, investments that are largely written off, well established processes and procedures, etc. Also innovation is hardly found in such an environment.

For a well-run company the approach is always that the current revenues fund the investments for the next big thing. Cutting back on emerging business either means that people have meanwhile realized that it is not such a great idea as initially thought, or that the situation is really bad. But I think it is mostly about personal bonuses of managers and nothing else. Yes, that sounds cynical. But if you have looked the history of businesses in the last couple of decades, it is the most probable cause.

 

Why People Dislike Brainstorming Sessions

When a group of people is assigned a task they never had to deal with before, they often start with brainstorming. So you have a number of folks who typically are not exactly knowledgeable about something, but at the same time try to agree on an approach for dealing with it. So they start with a discussion on what to do, who should be assigned what activity etc.

The problem is, that this is not brainstorming. It is group of people talking about something that they do not know much about. So a lot of assumptions are made, often not even consciously. People will simply extrapolate their past experiences into the new topic. But this approach does not deliver particularly good results.

The relatively obvious problem is inefficiency. Instead of the whole group talking 15 minutes about something, prior research by just a single person would have produced at least the same result. (Well, probably a better one.) The bigger problem, though, is about effectiveness. In other words: The result of the group discussion will usually not be a truly good solution. Again for lack of research and knowledge.

From a team dynamics perspective there is another problem. There are people who tend to dominate such free-floating discussions. Apart from personality, the folks talking most are usually those that know least about the subject. Because those that understand things at least partially, know that it is not so easy. But there is no time for careful deliberation during such a meeting. So decisions are made based on the least helpful content and the people who know best go out of the meeting frustrated.

Luckily, it is very easy to overcome this. Just task people to do some research on their own before the meeting. You will have a much more thoughtful discussion.

“You are not done, when it works”

The title is a quote from Robert C. Martin during a conference talk on clean code. For a long time now (I am getting old) I have followed this approach and it has produced remarkable results. For a bit more than four years I had been responsible for a corporate integration platform. I had built and run it following DevOps principles so that everything was fully automated. No manual maintenance work had been necessary at all, log files were archived, deleted after their retention period etc. This had freed up a lot of time. Time which I used to keep my codebase clean.

Particular focus was put onto the structure. And that had been a really tough job. Much tougher than I anticipated, to be quite frank. But I had paid off. Instead of writing a lot of conventional documentation, the well thought-out structure allowed me to find stuff in a completely intuitive way. Because, believe me, six months after you have written something, you do not remember much about it. But if you need a certain kind of functionality and do not only find the corresponding module immediately, but also from a first look make a correct guess how the parameters are meant to be used, that is truly rewarding.

Having experienced this first hand has greatly influenced my work since then. And I am more convinced then ever, that this is not beautifying for the sake of it. But instead it is a mandatory requirement and a prerequisite for business agility.

Giving Space to New Team Members

What is management about? According to my favorite podcast, Manager Tools, as a manger you need to achieve results and retention. Pretty obvious on the one hand. But terribly difficult to implement, especially if you want to balance things. One aspect is how to integrate new members into the team. If you have not read my post on what actually makes a team, please go here first.

When you join a team you are the “freshman”, at least in terms of team dynamics. Not so long ago I had switched teams myself and after quite a few years found myself in that role again. I had gone through this process quite a few times, either within an organization or combined with a complete change of employer. Different this time was that from day one I was officially in charge of two knowledge areas (architecture and DevOps) in a global function. 

This was an interesting experience, given the combination of being team freshman and subject matter expert at the same time. So I had to balance what I consider appropriate behavior for someone new to a team, with demonstrating thought leadership in my areas of expertise. I knew most folks from previous interaction and regarded them very highly for what they had delivered in the past. And seeing how they treated those team members that I did not know yet, I was quickly convinced that those were top performers, too.

From the receiving end, I was welcomed very friendly and that included the same amount of teasing everybody else received and gave. It was clearly a warm welcome for me and I truly appreciate(d) it. My colleagues also gave me the distinct feeling that my input was seen as valuable to the team as a whole. Or in other words: They gave me space to define and fill my role, which is much more than your official job description.

The tone for this was set by management and, as with so many other aspects, followed by the others. This is classic leadership by example. Of course, if you have a jerk on the team it will probably not help very much. But it is absolutely the manager who sets the tone. A few years ago I first hand experienced how a new boss literally killed a weekly team call that had gone successfully for years in just a fortnight.

An additional aspect for people who just started their career is letting them establish themselves in the organization. Especially for engineers who tend to be more reserved and have a somewhat introvert personality, which from a scientific perspective is different from being reserved (for more details, I have linked a video in this post). These people need to be given opportunities where they can demonstrate their capabilities in a “safe environment” and then be recognized for it. They will flourish in such a setup and typically deliver much more than you expect.

The worst thing you can do with such folks is to shout them down in meetings or conference calls. Very quickly they will go silent, suffer quietly, and start looking for somewhere else to go. This is one of the reason why leading a group of software developers is very different from e.g. marketing folks. But that is for a different post.

DevOps and Ownership

“You build it, you run it” has been my mantra for many years now. A number of times I was approached by management and they asked who should be operating stuff that I had built. Because, allegedly, my time was too precious for doing such a mundane task like operations.

This is to all managers: Operations is neither mundane nor something for junior staff. It is in fact exactly the opposite. Operations is what keeps the organization alive. Operations is where the best people should be, because here the rubber (the developed software) hits the road. Operations is your last line of defense, when (not if) something goes catastrophically wrong. Operations is a key influencing factor on your organization’s ROI. Operations determines your ability to be agile on the market. Operations is key for customer satisfaction. I could go on and on, but likely you long got my point.

Of course there are some aspects to operations that, when things are done the wrong way, are repetitive and far from challenging. But that should mostly be behind us. Yes, in the 1960s we had people who did nothing but enter data. And until not too long ago a lot of operations was just ticking off check boxes on a to-do list. But with things like infrastructure as code (see my recent post on starting with Chef Infra Server), this should really be something from the past. What you need today are people who take pride in running a lean, highly automated, highly resilient IT organization.

And that is where it should be clear to everybody, that DevOps is much more about organization, knowledge, and collaboration beyond traditional “borders”, than about technology.

By the way: My response to management about who should run my stuff, has always been “me”. Because the applications were built to be as maintenance-free as possible. Only the occasional support ticket had to be answered and with proper logging/auditing that is nothing that takes a lot of time. And fixing the occasional bug was not a big deal either, thanks to Clean Code and test-automation.

This allowed me to support 6 business-critical applications as a “side-project”, i.e. no time was officially allocated. Comparable applications operated by other departments had at least three people full-time for support only.