Employment Perks for Enterprise Architects

While other IT demographics are starting to get perks such as the ability to work from home, this opportunity usually isn't afforded to those who practice enterprise architecture...



So, if you can't work from home, then what perks are most appealing to you? In conversations with other enterprise architects, the following perks seem to rise to the top.

1. A boss that understands technology. To always have to be on your A game is tiring. Wouldn't it be nice every once in awhile to be able to have a conversation that isn't so distilled and dumbed down?

2. A comfortable chair instead of whatever the leasing company gives us. We sit on our butts a lot and having a nice chair of our choosing goes very far.

3. The sense that attending conferences and education is encouraged, not merely allowed. The ability to network with our real peers allows us to learn, grow and see things that otherwise keep us blind.

4. A career path. No, I am not talking about the abstract stuff drawn by folks in HR. A path that leads them to being CIO and being preferred over outsiders.

5. Give me leeway to be myself. Perception management is important but focusing on whatever it takes to enable the strategic intent of the business is more important. Putting my feet on my own desk is perfectly acceptable behaviour, as is listening to music, eating, having pop on my desk etc. As long as I'm not disturbing anyone else's workflow and I'm meeting all my deadlines/objectives, that's all that matters.

A Conference is about Community

I loved the followup to a previous blog entry where the notion that a conference is about community was spot on. Of course, I still have some challenges in terms of perspective that I would like to share.

1. I bet if you ask a lowly developer why they attend conferences, the answer would be along the lines of learning. If you ask the same question to a CIO it is about networking where the speakers are less important. So, not everyone has the same motivation for attending.

2. So, if you are a CIO, then you can network equally as well wandering the hallways of a conference as well as you can do by attending a jazzy party or playing golf with your peers. You have to ask yourself which one is more fun and accomplishes the same goal?

3. So, do you think people attend Gartner conferences to gain sage wisdom from industry analysts? If that was the case they could accomplish this goal by simply picking up the phone.

4. Even if a conference cares about educational value, are all attendees valued the same? Of course not. I would argue that the average developer in a large enterprise is more important in terms of free admission than someone who runs a small two-person consulting firm.

5. To support the above point, there are a class of emerging conferences that are 100% free to attend. They like us enterprisey types and eschew those who work for consulting firms. Are they also wrong?

6. I can say that the the plankton known as attendees are moving away from Gartner and RSA towards venues such as OWASP where both vendors and attendees can have the best of both worlds.

Why CIOs don't respect competent software developers...

Programmers are detail oriented. If we leave out one character by mistake they can introduce a subtle data corruption bug or a crashing bug.



Programmers work very hard to say exactly what they mean. When interacting with programmers, it is easy to get the sense that they are pedantic assholes because they are frequently asking for clarification on trivial points that you haven't thought about or correcting what seem like unimportant mistakes in what you say.

What you need to understand is that all of those annoying pedantic points are things that they need to understand, and that they need to understand correctly, if they are to have any hope of giving you anything useful.

The typical computer program cannot have judgment. It cannot "understand" much of anything. It mindlessly follows a bunch of instructions, no matter how sensible or stupid those instructions are. Getting those instructions right is our job, but in order to do it we need to understand the task at hand. Programmers need to understand it completely, unambiguously, down to every last decision, without any "rules of thumb" or "do what makes sense" type of steps, not even any trivially insignificant ones.

Also, Programmers tend to complain when you change your mind about what you want after we have written it. This is because programs are delicate things. They tend to only be easy to change in ways that they were designed to be changed. Changes that were not anticipated in the initial design can be very difficult and time consuming, and are dangerous as they can introduce subtle bugs. If you think over your experiences, I'll bet that most of the time when a program took longer to deliver than you wanted, you changed your mind about something after development had started.

Now you might have thought that the change was a small one, but it probably wasn't small at all to the programmer...