Tag Archives: Management

Too Qualified to Code

There is an “interesting” perception of software development in that quite a few people think it is an activity suitable for graduates but not highly qualified professionals. I am in violent disagreement with this. But since it is a widespread belief, just dismissing it as dumb does not help very much. So how does it come that so many people, who have a somewhat limited knowledge about the subject, make such a judgement and act according to it?

From a psychological point of view there seems to be a mechanism in place that either makes those people believe that they actually understand the subject enough to make an informed decision. Or they do not see it as important enough to invest more time in the whole process and just go for the easy way. Or something in the middle? I will look at some thoughts I have had on the topic over the last couple of years and hope they make sense to you.

If you look at how most companies handle careers, you will soon realize that many talk about career paths for managers and professionals. And they are usually eager to say that both are valued equally in their organization. Well, I have yet to see a place where this statements, typically coming from HR, survives the reality check. If the entire organization is run such that managers from day one experience that the “techies” (sometimes lovingly referred to as code monkeys) are just there to serve management without questioning its wisdom, guess what happens.

Most professionals will simply do as they are told and not start a discussion why something is possibly not as easy or brilliant as it looks from the business side. Managers, and that is absolutely the techies’ fault, will then start to believe that they know enough about technology to decide on details. And the next time, when they do so and the techie just nods and goes away to deliver, they expect a good result. If the result is not so good though, because many details were not taken into account, it is indeed the techie’s fault to not have brought them up. And, voila, there you have the vicious circle.

I must say that I have been fortunate enough so far and not run into that situation. But that not only requires experience and the “standing” in the organization, it also depends on your financial independence. I live in Germany and we have laws against my employer just firing me, because I am not obedient enough but quite a nuisance instead. So in that respect I am just lucky. But your standing with management is something you can and should control. If you are too quiet and never give them a chance to learn how thoughtful and interested in the company’s progress you are, how should they know?

What has worked nicely for me is not trying to be someone else but find opportunities where I was on my home turf and still talk about something they were interested in. And in a nutshell the message I got across was: I understand and want to support what you need to achieve; and for the technical details you can rely on my experience and let me decide on the nitty-gritty stuff, which you are not interested in anyway.

And with this you are not talking about coding any more but supporting the business. Yes, actually performing this support means coding. But once people see that they are much better off with you doing this, rather than someone less experienced, they will happily accept it.

So how can you proof that your experience is relevant to the business? By keeping your promises and deliver on time, quality and budget. Because you have gone through the learning curve and know all the potential pitfalls that can happen for a given task. Having them taken care of upfront and not let surprise anyone, you keep things under control. Just a few weeks ago one of my projects went live and my counterpart from the business side was thrilled that there was only one bug discovered, and fixed immediately, so far.

Fixing things quickly and effectively is, by the way, one of the most powerful tools in your arsenal. Nobody expects a bug-free software, especially if it is custom development. But what people want, and rightly so, is that you can fix things fast. So invest time and have a system in place that allows you to ship fixes in no time and without interrupting normal operations. If you need to tell the business that a two-hour downtime is required for you to bring a fix into production, you are really not worth your salary.

That’s it for now. I know that I barley scratched the surface of a very diverse topic. But everything needs to start somewhere …

Size of Development Teams

What is a good size for a development team? Of course there is no truly universal answer to this question. Software projects are just too diverse. But still my gut feeling as well as several articles I read on the subject, tell me that in many cases two to five people is probably a good initial estimate.

Obviously this excludes things above a certain size, like operating or ERP systems in their entirety. But change the focus to a module of the aforementioned and all of a sudden the team with five people is not so ridiculously small any more. So, like in many other cases, it all comes down to scope.

My general line of thinking is this: When something is too big for five people, it comes with an inherent complexity that will increase the likelihood of failure considerably. Of course, you can throw more resources at the problem. But you will get all the by-products of that. Think about communication overhead between developers, additional management layers, and the increased risk of low-performers among all the people that are poring in.

Interestingly, you can also approach things from the opposite direction: I was once told a story about a CEO who reduced the size of a development team to get things done better. At the time I thought this was a ridiculous approach. But I have long changed my mind since then and wholeheartedly agree. It is a bit like the inverse of what is described in “The Mythical Man-Month“, where Frederick P. Brooks, Jr. describes the naive idea that adding developers will shorten the time needed to accomplish a certain goal.

So in my view the goal should absolutely be to to have development teams no larger than five people. If the overall project is too big for this, you need to slice it into parts that can be delivered by small-enough teams. This will also help to enforce clean interfaces/contracts between the various parts.

All of the above assumes that we are talking about people with considerable experience (5+ years) in the relevant area. Given that the average experience of software developers is about five years, it will often be challenging to staff such a team. (And five years average is for their entire career, not the relevant subject area.) But dealing with this, is the topic for a different post.

“Decisions should be made at the lowest possible level”

When watching this video about The Origins of Hewlett-Packard, one of the statements that really struck me (at time code 16:25) was “Decisions should be made at the lowest possible level”.

I have had the privilege to work for Hewlett-Packard as my first job after graduating from university. It was a turbulent time then in 2001, when the dot-com hype was just “exploding”. But it was also a period, when many colleagues were still around, who had been with the company for a very long time. So the HP way was still alive and kicking, at least in my personal environment. Sadly though, ever since, my personal opinion has been that the company is in a downward spiral. It was certainly not a good sign, when under Carly Fiorina as CEO the founders’ names were officially removed from the company name and the latter reduced to their initials. I have left HP in 2005 but still feel connected. Therefore it really hurts to see what has happened to the company. And I always look back at those early years of my career with a lot of fondness!

But I should come back to the subject of this post. Having read, experienced, executed, and thought quite a bit about management, I really do think this is one of the (!!!) core aspects: Where should decisions happen? And especially in today’s times, when everybody is talking about “the quick eating the big”, it should be a no-brainer that the right level for decisions is one of the most critical components for success in business. Why is it then that we still see so many organizations where mid- to high-level executives lead with a micro-management style?

One fundamental question here is how people act in their professional environment. Do they try to avoid mistakes? Or do they work to achieve a common goal? I daresay the former behavior breeds micro-management as a strategy to mitigate risk. Of course, the result is local optimization, at best. But overall the organization will fall back in the market, perhaps live from its past for a while, and eventually disappear.

My hypothesis is that trust, or lack thereof, is the major driving force behind this. And it is usually the top management that sets the example here. The good thing, though, is that they can also change it. In his famous book “Turn the Ship Around!: A True Story of Turning Followers into Leaders” L. David Marquet does this on a nuclear submarine. And if it works for what is probably one of the most dangerous working environments on earth, it works everywhere. (The book is a must-read in my opinion for everybody who has only the slightest interest in things like management, corporate culture etc.)

I do expect that we will see many traditional organizations moving away gradually from a pure top-down management style. Partly because of market pressure for agility, and partly because employees simply demand it. So we have interesting times ahead of us!

Choosing a Technology

I recently started a new hobby project (it is still in stealth mode, so no details yet) and went through the exercise to really carefully think about what technology to use for it. On a very high level the requirements are fairly standard: Web UI, persistence layer, API focus, cross-platform, cloud-ready, continuous delivery, test automation, logging, user and role management, and all the other things.

Initially I was wondering about the programming language, but quickly settled for Java. I have reasonable experience with other languages, but Java is definitely where most of my knowledge lies these days. So much for the easy part, because the next question proved to be “slightly” more difficult to answer.

Looking at my requirements it was obvious that developing everything from the ground up would be nonsense. The world does not need yet another persistence framework and I would not see any tangible result for years to come, thus loosing interest to soon. So I started looking around and first went to Spring. There is a plethora of tutorials out there and they show impressive results really quickly. Java EE was not really on my screen then, probably because I still hear some former colleagues complain about J2EE 1.4 in the back of my mind. More importantly, though, my concern was more with agility (Spring) over standards (JEE). My perception with too many Java standards is that they never outgrow infancy, simply because they lack adoption in the real world. On the other hand Spring was created to solve real-world problems in the first place.

But then, when answering a colleague’s question about something totally different, I made the following statement:

I tend to avoid convenience layers, unless I am 100% certain that they can cope with all future requirements.

All to often I have seen that some first quick results were paid for later, when the framework proved not to be flexible enough (I call this the 4GL trap). So this cautioned myself and I more or less went back to the drawing board: What are the driving questions for technology selection?

  • Requirements: At the beginning of any non-trivial software project the requirements are never understood in detail. So unless your project falls into a specific category, for which there is proven standard set of technology, you must keep your options open.
  • Future proof: This is a bit like crystal ball gazing, but you can limit the risks. The chances are bigger that a tier-3 Apache project dies than an established (!) Java standard to disappear. And of course this means that any somewhat new and fancy piece must undergo extreme scrutiny before selecting it; and you better have a migration strategy, just in case.
  • Body of knowledge: Sooner or later you will need help, because the documentation (you had checked what is available, right?) does not cover it. Having a wealth of information available, typically by means of your favorite search engine, will make all the difference. Of course proper commercial support from a vendor is also critical for non-hobby projects.
  • Environment: Related to the last aspect is how the “landscape” surrounding your project looks like. This entails technology but even more importantly the organization which has evolved around that technology. The synergies from staying with what is established will often outweigh the benefits that something new might have when looked at in isolation.

On a strategic level these are the critical questions in my opinion. Yes, there are quite a few others, but they are more concerned with specifics.

Leadership Lesson from a Nuclear Submarine

The video linked below is a quick summary of how the captain of a US Navy nuclear submarine turned his crew into the best evaluated ever. It is a remarkable story and reiterates in a very comprehensive and compact way what I have experienced myself many times (on the giving as well as the receiving end).

I was made aware of this video by a post from Torsten Bittlingmaier. Thorsten, thanks a lot!

Eric Ries: “The Lean Startup”

I stumbled over this when reading a German article about the Visual Studio ALM Days 2011. Eric Ries basically makes the argument that startups, like any company, need management; you cannot expect to succeed without it. The key point, though, is that a special flavor of management is needed, which is tailored to the specifics of startup companies.

When looking at the reviews at Amazon, it becomes apparent that the author has hit a nerve. Although not all of them are really enthusiastic, already their sheer number (142 as of this writing) is interesting. I will not repeat things here but provide a few of my thoughts:

  • First of all, I was reading this not from the perspective of someone who works for a startup or wants to create one any time soon. Instead my background is on distributed systems working for a well-established software company. So the aspect of how to change innovation within an existing organization was the interesting part for me.
  • The key aspect I took away was that in many, many cases it is better to start building something quickly, fully accepting that the initial solution is far from perfect, and get feedback fast. This also coincides with my observation that most people have great difficulty to really grasp and understand something really new. Instead of spending much time on slides, just do a mock-up or prototype and some screenshots and all your discussions will be much smoother.
  • If you expect checklists and concrete advice for your particular situation, you will probably be disappointed. I would argue, however, that the book’s approach to tell you how to think is certainly better than to have a one-size-fits-all list of things to check off.

Overall I enjoyed the reading and fell that it has expanded my way of thinking. Also, I found quite a few parallels (e.g. with agile software development) and this reiteration has helped to “persist” things in my mind.

Getting Someone’s Buy-In

Recently, I came across a very interesting post on Harward Business Review’s blogs. The article from Peter Bregman is called “How to Counter Resistance to Change” and I recommend you read it and also scan the other posts from the author. The part that will probably create a few raised eyebrows is when it advises against getting buy-ins. Well, at least in the dumb way this is usually done: In most cases I have personally experienced, what people effectively did, was try to persuade me (or even talk me to death). Folks, this is not getting a buy-in, this is talking someone to death.

In my view getting someone else’s buy-in usually means that the other party needs to change, at least partly, a position they had taken before. To make matters more difficult, in many cases the incumbent position has also been communicated to others, so we add the not-loosing-face factor to the equation. Variations of the latter are things like being seen in control by superiors as well as subordinates. But also the impact on relative strength perceived, compared to the person that gets his or her own view through, plays a role. So all in all this is quite a minefield and careful handling is required from a short as well as a long-term perspective.

What I found particularly interesting, or rather amusing, is that the author’s approach is something I also heard about in a TV series where it was called the “horse dealer’s approach”. So nothing really new, but still very relevant to many situations. Also, you can look at it as identifying a given pattern in as many different scenarios as possible. I am very much someone thinking in patterns and always find that one gets tremendous insight into the core of something following this approach.

Processes and Process Orientation: Introduction (Part 1)

This post is the first of a series aimed to give a general overview on processes and how they have affected the way we look at how organizations achieve their goals. The text is somewhat academic in nature but I still encourage you to read it. Understanding the basics and (theoretical) concepts is always helpful when it comes to practically dealing with specific challenges.

The series is based on a paper I wrote during my time at university in 1999/2000. (For those who don’t know, I read business management and not computer science or some kind of engineering.) While the paper itself was done purely out of interest for the subject and not for any course, it was triggered by a seminar for which I had to look at processes in the context of the Balanced Scorecard (BSC). I then added a few more things and made it a separate text. So here we go …

Introduction

The process-oriented approach became mainstream in management theory in the 1990s. This was a move away from a mainly functional view that had been the predominant paradigm for many decades. A functional touch can largely still be found when you look at the orgchart: Purchasing, marketing, HR, etc. are all functions and will probably be around for quite some time. But instead of focusing on those functions, nowadays people realize that cooperation across the board is necessary to deliver something useful for the customer.

The old, functional approach with its clear separation of responsibilities was, in a way, a consequence of the work done by Frederic W. Taylor on scientific management. This mainly focused on  improving efficiency by splitting up work in many discrete steps. First steps towards a more process-oriented way of doing things came from these areas:

There were a few points that triggered this re-thinking which I would like to mention here.

  1. A functional approach severely limits the organization’s capabilities to be customer-driven (see above)
  2. A process-oriented organization increases flexibility
  3. Processes, or more precisely the thoughts required to define them, greatly improve the understanding of complex commercial activities
  4. Overhead costs need better distribution

As with so many things, this re-thinking was mostly triggered by difficult economic circumstances.

Part 2 will give a definition of what a process actually is.

Work Breakdown Structure

The Work Breakdown Structure (WBS) is a pretty well-known tool for managing projects. It is a formalized way to split a complex task into many small (and by that more easily manageable) parts. So instead of “install computers in rack” you have list with e.g. check availability of rack space, request network and SAN connection, arrange date/time with computer center, etc. This is probably a bit simplified, but you get the point.

I use the WBS a lot as soon as things become a bit more complicated. May favourite tool are spreadsheets, which have the following advantages:

  • Everbody can use them
  • You can send them around via email very easily
  • Versioning is easy (via naming convention or use of a proper version control system)

What attributes should be maintained per task? I have the following:

  • Task ID: Never use the lines from Excel. A simple re-sorting and you are screwed
  • Status: green, yellow, red
  • Progress: open, done, wip (work in progress)
  • Area: Whatever makes sense to you. Examples: architecture, infrastructure, project management
  • Owner: The person responsible for the task towards management. Please note that this guy is not necessarily the one who does (all) the work.
  • Due date
  • Description
  • Activity log: Whenever something happens for the task, make a note with the date and your initials (you may not be the owner)
  • Task ID cross-reference: Relationship to other task(s)
  • External cross-reference: E.g. task relates to specific section of document

Depending on your requirements you may need additional information. You can also leave out some of the things from above, although I would discourage that if you don’t really know what you are doing. This list has been developed over a number of projects and sooner or later I was always thankful to have them.

So what is the relationship of the WBS to a project plan? The latter is generally more high-level, contains explicit dependencies, is more used to communicate with management. In many cases one line item in a project plan is basically detailed out by a WBS