BLOG:JUEL:ME

I started my new job this monday, and although I have only been here for a week, I thought a small blog post was in order.

Basically, I have changed industries. Whereas I used to make software for a software company, I know make software for a financial institution, or market maker as they would call it at the Stock Exchange.

Granted, I have not been here so long that I can write a comprehensive post about the suttle differences between the two industries, but I am quickly forming an opinion. Simply put, the world of finance is much more structured the the world of IT as I have experienced it so far. Of course, I came from an SMB and moved to an enterpise sized organization, but the attitudes are very different.

The finance guys seem much more focused on planning and analyzing, whereas the IT guys guys seem focused on execution. At Evenex we were able to think up something in the morning, and start developing in the afternoon. It’s a gross exaggeration but you get the idea. In the finance industry, so far at least, the emphasis on project models and methodologies are pervasive and very important to the development.

It is way too early for me to form an absolut opinion on which I prefer, but so far I am really liking the fact that I have the time to perform the necesary analyses before we start to actually code.

Before I get going on my rant here, let me just point out that I am not bashing anybody here, not even my own employer. And if I am bashing anyone, it is “the man” who in this case is synonymous with big faceless corporations here everything is systemized and all actions are controlled by over-zealous managers and time sheet keepers.

So anyway, I was reading this article on my iPad earlier, which talked about why people in Seattle all of a sudden wanted to work for Amazon again.

Amazon has been a cornerstone in Seattle for more than 15 years now, but it wasn’t always seen as a great place to work.

Employees talked about long hours and a pressure-cooker atmosphere, and the core business — e-commerce — didn’t seem very sexy.

What a difference a couple of years can make.

Over the New Year’s holiday, I visited Seattle for the first time since late 2010. A bunch of people in the tech scene told me the same thing: Amazon is THE place to work now.

Here’s why….

Read more: http://www.businessinsider.com/why-everybody-in-seattle-wants-to-work-for-amazon-2012-1#ixzz1in1ItJik

Source:  Matt Rosoff @ Business Insider

I have been a huge fan of Seattle’s for many years. In fact, so much so that I did part of my Master’s degree there (well, close to anyway) and married a woman from Seattle, to whom I have been married now for almost eleven years. That is still not the point though. As it states in the article, Amazon has a new HQ close to downtown, which is walking distance to pretty much everything. Furthermore, there are all kinds of Googlesque benefits for the employees, which is also a nifty thing I’ll admit. The really interesting thing though, is how the local area area has developed explosively since the move, because so many people now work there.

And so I wonder. I wonder why that kind of approach has never really taken off here in Denmark. I mean, I for one have never heard of any company that takes really makes a point out turning the HQ into a place where people actually want to spend their time. For that matter, I have never really seen any places in Denmark, where the campus has been designed to allow people to be creative or innovative.

In my younger days when I was a consultant I visited a lot of customers and I never encountered anything but standard Lenovo PCs, Nokia phones and crappy coffee.  There’s nothing wrong with Lenovo or Nokia at all, actually the both make some really cool stuff, my is this though; everything is so standardized around here. We use the same tools, we runs our businesses the same way, and we never really seem to actually create something new. Considering how we consider ourselves well educated in this country I find it a little odd that we do not have any real startup culture here.

My stipulation is of course not right. We do have start ups here, that seem to approach the whole business life somewhat different than the bigger guys. Tradeshift and Podio are really good examples of companies that do not adhere to “the rules”; companies that are not afraid breaking some norms in order to do new things, and do them differently.

Perhaps it would be easier to make the employees “live the brand”, be more efficient or even more loyal to the company.

I had a presentation today for a whole bunch of people. These guys were from all over the company; implementation consultants, service desk employees and sales people. When you think about that is a fairly diverse group of people. As I was standing there taking the usual abuse why we didn’t do this or that, I came to realize how many stakeholders I actually have, and skewed my time table is, considering who I spend my time on these days.

These days I spend a lot of time with development team in Manila. It is a group of very talented developers and testers, but since they have no experience with this kind of application, we are spending a lot of time attempting to transfer the necessary knowledge. Unfortunately that means that I have neglected my usual stakeholders. So, just for the fun of it I decided to use my Friday evening on making a diagram of all the stakeholders I have as a product manager. I know I need a life, but be that as it may, you can see the diagram below.

I know I should have made a Visio diagram, but even I have my limits, especially on Friday evening. So anyway, what does this over simple drawing show? Basically, it shows that top management wants to develop some kind of feature. It can either be to position the product in the market or to live up to contract requirements etc. Normally, product management would have a pretty big say in these decisions, considering we are supposed to know not only the application but also the market, the users and the competitors.

Firstly, we need to coordinate with the development department. How are we going to solve this issue? How does it fit with the existing code? These discussions are usually quite iterative in nature and result in a specification, which in my case is a user story.

And this is where I believe the flow must never stop. If we are to really capitalize on our investment in the product, we need to tell the sales force what they are going to sell and why. We need to tell consulting how it works and how it is implemented. We need to tell operations how to support this new feature and finally we need to provide input to marketing about what they should say to the market.

All of these tasks make product development a complicated task, because even if the arrows above only point in one direction, they should also go the other way. Most departments have requirements to our product. It should be sexy, so it is easier to sell, it should be robust so it is easy for operations to support it etc. And this leads me to the point of this post, and the point is that perhaps the most intricate part of the PM’s job is to ensure profitability on the products. We derive profitability not only from the top line, meaning revenue, but also by ensuring that the software and services we create are easy to work with so the organization does not need to spend a lot of resources in order to make this thing work. This also means that, at least theoretically, that it will be more profitable to say no to the customer, if they request a feature we cannot sell to other customers, or that the operations are too high or even if we move beyond our product domain. Not exactly a popular opinion among all people, but nevertheless an argument I fully believe in.

If we applied general systems theory, we could draw a diagram of subsystems that are intertwined and together form the basis of our return on investment.

Last week I went to a Tech Talk at Microsoft where we talked about Lean Product Development, a topic that is near and dear to my heart. One of the main points was that resource utilization of 100% is not necessarily a good thing. Those of you who have a project manager or two breathing down your neck every day, know that they are usually looking to reach 100% utilization, because in their world that is where we reach optimal productivity. Now, don’t take this as me bashing project managers. They also have people breathing down their necks, because they have a release to deliver.  If anything, this post should be seen as a polite reminder to top management that product development is very difficult to fit into an Excel spreadsheet.

So, now that I have gone to great lengths to be civil to everybody, what is my point? It’s very simple; the unpredictability of the software development process is so explicit that we need to leave room to fix the things we were unable to foresee when we planned the project. Don’t get me wrong, there are things we as product people don’t necessarily need in order to launch, but let’s face it, most of the time we deal with the issues that will severely impede the use of our product unless they are dealt with properly. By subscribing o this notion, I have essentially said that slacking on quality is a non-option. This leaves time and scope as the only variables we really want to touch.

I am pretty sure it is easy to come up with examples that contradict my point, however, there’s a reason why I think we avoid 100% resource utilization and why we should never compromise on quality. Uncharacteristically, the argument is an economic argument, and ties to my earlier rants about the brand. We cannot afford to have our users, and of course decision makers, being negative towards our product. The negative connotations and the reputation we encounter in the marketplace if our software “doesn’t work” will most likely impede impede on our ability to perform in the marketplace.

If we produce a Saas application, our financial model is based on an investment in a generic product, which more or less works for everyone. So, if we view our Saas application as our asset, we can calculate the Return on assets. Basically, our return will be dependent on our ability to resell the application after we have reached the break-even point. If we decrease the brand value in the minds of our users, by creating software that “doesn’t work” we are most likely not going to be able to capitalize on our initial investment.

ROA=Pnat:A

Where

ROA= return on assets

Pnat= net profit after tax

A= assets

In all honesty, I have never applied this equation to my own real work life, mainly because it is not something that is really part of my everyday tasks these days. However, I think that equations like this can work as powerful tools for PMs, when attempting to persuade management and other stakeholders why we should never go with a 100% utilization of resources.

I will update this post if my own CEO buys it

Fordelen ved at arbejde i en IT virksomhed er, at man har en masse licenser til det nyeste Microsoft software samt at man kan risikere at falde over en laptop, som alle havde glemt alt om. Jeg har været så heldig at falde over en laptop, som rent faktisk kan køre Vista med Aero og hele dynen. Min Vista score er godt nok kun 2.0, men det er nok til at jeg kan bruge alle de nye features.

Samtidig er dette min første blog post med den nyeste udgave af Windows Live Writer, så et eller andet sted er der meget at glæde sig over. Der er lidt stress på i øjeblikket, så jeg har desværre ikke tid til at teste Writer så meget som jeg gerne ville, men da jeg blogger både her og ovre på min corporate blog burde der være rig mulighed for at få afprøvet den.

Mht. Vista, så er der umiddelbart ikke så meget at sige om det. Det er stadig Windows på godt og ondt, men Aero er efter min mening helt klart med til at gøre det meget mere behageligt at arbejde en hel dag for computeren. Faktisk er jeg så begejstret for det, at jeg tror jeg vil fremskynde mine planer om at købe mig en ny PC. 

Technorati Tags: Windows, Vista