Category Archives: Management

Architects Should Code

There is a widespread notion, that developers at some point in their career evolve into something “better”, called architect. This term has the connotation of mastery on the subject, which I think is ok. What is not ok for me, is that in many cases there is the expectation that an architect’s time is too valuable for something as mundane as coding. Instead architects should develop the overall architecture of the solution.

Ok, so what is the architecture? Most people believe that some documentation (often a mixture of prose and high-level pictures) is the architecture. I would argue that this not the architecture but a more or less accurate abstraction from it. When enough work has gone into things, it may may even become the to-be architecture (but certainly not the as-is one). However, outside of regulated industries I have never seen a document that was thorough enough. A friend of mine used to work on embedded systems for car breaks where lives are at stake; and he told me some interesting stories about the testing and documentation efforts these guys take.

In my view the architecture is, by definition, in the code itself. Everything else is, I repeat myself, something that has some relationship with it. So how can an architect not be coding? You could argue that instead of doing the work him- or herself, mentoring and guiding less experienced developers is a good use of the architect’s time. For me that works fine up to a certain level of complexity. But if we talk about an STP (straight-through processing) solution, is that really something you want to give to a mid-level developer? (It would probably be an ideal piece of work for pair-programming, though.)

I do certainly not want to demean people who call themselves architects. It is a not-so-common capability to look at an IT landscape and see the big picture. Instead many people will be lost in the details. So we definitely need this this perspective! But it is a different kind of architecture, the so-called Enterprise Architecture (EA). I know folks who started as (really good) developers and are now very successful at Enterprise Architecture.

So, in closing, my core point is that the architecture of a solution and its code are basically two sides of the same coin. Everybody involved on the technical level should understand both aspects. And if the level of detail varies, depending on the official role, that is probably ok.

“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: Functional View and Process Types (Part 3)

After the definition let’s look at what practical relevance all this has. For me the most important part is a shift of perspective. The functional view is mainly about the orgchart and who needs to do something, whereas the process-oriented one is about what needs to be done. Hopefully, the picture below illustrates this.

Functional vs. Process View

 

Also, one should note that process-orientation is about two things:

  1. The concrete knowledge about interdependencies, what needs to be done where, etc.
  2. A particular way of thinking

Classification

The above picture shows a pretty generic example, which indicates that most likely there is a set of common processes across various verticals and organizations. And indeed, if you go through various publications you see a pattern even amongst the different classifications. The consensus seems to look like this.

  • Core processes
    • Create product/service
    • Market communication
    • Optimize value for customer
  • Support processes
    • Order processing
    • Logistics and customer service
    • Ensure profitability and liquidity
    • Capacity planning
    • Staff training, motivation and retention
  • Management processes
    • Plan and implement strategy

An interesting part of looking at processes is the identification of patterns across organizations.