How to hire a product manager...

There was this blog post, about 10 years ago. The subject was "How to hire a product manager". Its one of those blog posts many folks read, and which ends up being referenced here, there and everywhere.

Interestingly, the author of it has done a retrospective post. He looks back 10 years, and examines the post and what is good and bad about it. Check it out, for the comments from some of the good and great from the world of PM, and related fields. Interesting to see folk being critical about logic puzzles. I have conducted hundreds of interviews and really always wondered what value you got by asking someone how many golf balls would fill the Aviva stadium or something. So I'm glad those questions are falling out of favour.

In open source news, Spotify have open sourced their internal monitoring solution. Now if you look into it, a large part of this solution is pulling together several different tools, mostly freely available. But it's still a great, proven enterprise toolset which is yours gratis!

A follow up to linux post..

As an interesting follow-up to the Linux post the other day.

I remember hearing about how Netflix were doing Continous Delivery a few years ago. There are a few videos out there about it. The one I link above is just one good example.

Last night Netflix open sourced their entire continuous delivery platform. Free. There is the code. Use it how and where you want. If we were to look back 15 years ago they would have spun it out into its own company and sold it as a product in its own right. But now, what companies are doing is sending the code out there. It's one part company prestige and another part a competition to get the best development talent. Not all financial decisions are just around yearly licence fees.

Linux in the Public Sector..

I'm a bit behind here so pardon the catch-up post! I missed the last couple of classes due to aforementioned baby stuff. I was reading the kongregate case with interest. First, the gaming world thought that on-line games would go this way at the given time. But they have not really. Mobile came from nowhere and killed services like this pretty quickly. Oh, and the fact flash is buggy rubbish with more security holes than one of Tony Soprano's waste treatment facilities did not help one bit either. Yes they still exist I'm sure, but they are small beer.

Second, I asked to do Financial Management as one of my optional modules this summer. So I had a wonderful time locked in a class room on a series of wonderful sunny days! All the while having to take time off from work, it was great! I was learning about WAAC, Payback periods, bond yeilds and what not. As an aside, this is a subject which I *really* think should be mandatory for any masters course in a top business school like ours. If we are being groomed to be the next generation of business leaders, we need to be able to read and understand a set of accounts. I want to understand why my former boss loved capital expenditure and hated operational expenditure. Prior to doing that Financial Management class I had no idea. So we need to come out of courses like this with more than the ability to make a project plan and/or a set of slides!

The Linux paper is fascinating. I remember maybe 15 years ago [around the time this paper was written] and a tiny number of Linux-based companies had decent venture funding. A common question being asked is if "serious" companies take the risk of using Open Source software. If the software was free, how could it match up with something coming from Microsoft or Oracle. What happened is that Linux is not any kind factor in the desktop market [for home or for business]. But it a gigantic player in the world of "*.* as a service". I would think if we looked at data centers around the world, I would think a huge percentage run some kind of flavor of Open Stack. Which is built on Linux, totally open source, and as good an engine and set of tools for running your own cloud based system as exists. If you think big data, I think you are frankly insane to look beyond Hadoop and the related Apache Foundation Projects which work with it.

Yes Oracle is maybe faster and better, but it also will cost you a very serious amount of money every year...forever! The open source solutions are free. You can download them, and fork or branch your code and work away yourself. But you have the bonus that many companies with serious development teams pushing code into the open source code base.

So if you're a government or other public body, why would you go with anything else?

Video & Project Submitted..w00t!!

Since I knew I would be having the baby I was a bit ahead of the game in terms of, coursework and project. So I submitted my video last night. It's nothing fancy. Its original text recorded on my laptop from my kitchen. Pixar alas were busy making movies which won't be quite as good as back in the good old days!

Today I submitted my project. It is based on an upgrade for a heavily modified CRM system. I tackle some of the issues which arose from that. It's always good to have a project like that completed. When you are doing something like that, over 5000 words. There is a lot of research involved and doing yourself justice requires work. But that is the whole point. It's like a triathlon or a marathon, if it was easy, everyone would do it!

Regarding the babies part of blog title

I mentioned babies in the blog title. Well my son Aengus joined us last Friday night.  I have attached a picture of him here.

What is interesting is that there was very little interaction with computers through the pregnancy process. You have a huge manual file,  which contains all your test results and all doctor comments. If that file is lost,  so are you basically. Its amazing our health system runs on this ancient technology. What computers we did see looked to be running Windows 2000 or XP, and we're deathly slow. We were getting blood test results and they used telnet to get to a text based server,  which only could hold results for a few months. So clearly a crappy AS400 on a garden shed somewhere!!

Would there not be a huge business there for the computerisation of hospital processes!

An interesting point of view...

I'm currently reading The Innovators, by Steve Jobs biographer, Walter Isaacson. It really is a brilliant book. The story in the book is that each chapter is a different evolution step in the history of computing. Where I am at now is that the computer has been invented. We are in the 70's and about to leap forward.

What I read last night is that Nolan Bushnell is starting to play about, and starting an evolution which shall soon end up with his developing Pong and founding Atari! The first thing he does is get a Data General Super Nova machine and tries to play about with them, to get his first game working. Keen readers will know, our friends in Soul of New Machine are trying to build a successor to this machine. [Im skipping over the Eclipse, as that is basically vaporware IMHO!]

This Super Nova machine is described by Isaacson as looking like a fridge. But he said that the Super Nova was slow and hard to use. So Bushnell moved on, and eventually came to the idea that he would build hardware, and go the coin-op route, and put the arcade machines in bars. Before he did this, the idea of computer games at homes and also of arcade machines basically did not exist.

This evolution is huge for the modern world of computing. Games and Graphics become a new driver of hardware and software. The computer begins to evolve beyond offices and databases. It's interesting in that light, our friends at Data General lost their battle before they even started. Their machine was doomed to fail for reasons outside of their control. This is a touch harsh, as the machine they built did well. But the market is served and the company themselves was already doomed.

Another interation..

It's the end of a long weekend, and alas I was not running the marathon or partying like a rockstar. I was either building flat pack furniture for our forthcoming baby or working on my project for this class. The simple fact is that with a baby due in a few weeks, it pays to be ahead of the game. That I am. But this bit is always easy, throw loads of words at the page in some kind of roughly aligned organizational structure. But then I must spend the same about of time implementing grammar, referencing, getting below the word count. Oh what it must be if one was a professional writer, and you could "throw it over the wall" to an editor, or indeed a team of editors in my case :D [as developers are so keen on doing, throwing their dodgy code over to QA teams!]

The Microsoft case study for this week is interesting. But its nothing new to me, really. We look at three teams at Microsoft, they adopt a new practice and are diligent about it. They are monitored pretty closely. I think any team of skilled people, [..with the eye of Sauron on them] will do well working with practices which break out their work and have clear tasks like this.

On this week's readings, Kent Beck is this week's interesting fellow. He was one of the brains behind the agile manifesto [so I have read in a few places, but I hazard a guess that more than person has that said about them], and was one of the initial folks who put their name to it. Now we move onto one of his earlier papers dealing with Extreme Programming. In my working life XP is a bit of a joke, a term of derision. But what he is clearly doing is pulling good ideas from here and there, and making a new thing. Not unlike Henry Ford coping meat packing practices when he wanted a way to make more cars, and make them cheaper.

But if you read what he is actually saying it's the direction a lot of software companies have gone. They work on loads and loads of small iterations. They want to get the software to their production servers as often as possible, many times a day if you are doing it right. You design, code, build, test and then deploy many tiny things, rather than big huge monolithic things [as Waterfall tended to do]. That way, if your Microsoft working on Office 365. You have a story to take advantage of 3D printing or something like that. You design that one thing in isolation. You get the team to code it. Then you release said enhanced printing function without having to patch a billion copies of office, or doing another release or something. You make your enhancements, release when it's ready, patch your host servers and you are done. Customers have enhancement. Back 5 or 10 years ago, that would be a feature lost in a big bang version of office which hit your desks every 3 or 4 years.

A Perfect World

I really enjoyed the Fishman paper, “They Write the right stuff” as it was an interesting view on ‘how the other half live’. You can see that if we had a tour of the NASA software development center that they do indeed work to the highest possible standards, and may indeed work to the strictest possible letter of the law of some set of standards like the CMMI guidelines which Royce describes in one of this week’s other papers.

A number of years ago I was building a testing team for a company who had previously not really cared about software testing. That company had previously believed that agile development meant that they did not have to test their code. They thought that they could push rapid fixes to their live environment, and this negated the need for any formal testing structure. [Note: This may seem almost funny now, but a lot of people and companies really thought at that time]. In building that team I interviewed a gentleman who worked for a company who wrote the software which tested artificial hearts and lungs. Imagine, my companies bug will cause us to need to push out an emergency fix out of office hours. His companies bug will potentially kill people! It’s a different mindset.

I think when we look at Fishman’s Nasa example anyone in “commercial” software development. The software at Nasa cannot have any errors, plain and simple. They have spent the time planning, and clearly have the people time and processes in place to ensure that it is perfect. As the article mentions “It is an exercise in order, detail and methodical reiteration”. I have spent my career in development teams at rapidly growing commercial software companies. Our focus is on getting “this” feature out, at the best quality possible in the time available, and to move onto the “next” shiny object feature. Our resources and timelines are driven by commercial reasons. The resources and timelines at Nasa are clearly driven by the need to get it right.

If you go to the next level of information in the article. One line jumped out at me, they speak about how they get to the near zero defect rates, “Packet data and view graphs on a line by line basis”. I read that and I genuinely wonder how ANY complex code can get passed that. But I have never worked in a zero defect environment, and clearly wont ever! In commercial software development, we fix any critical defects. We have logs, and basically ignore things below error level, any warnings or info notifications don’t even get logged in the defect system. Clearly at Nasa, they want the logs empty of anything. I cant emphases enough how huge of a mindset change this would be for most people.

Finally, there is one last thing to be pointed out. The article quotes someone at Nasa as saying, “Don’t fix mistakes, fix what permitted the mistake”. This is one of those things that everyone knows, but virtually no one follows through and puts into place. It's like when I lost a lot of weight a few years ago. People are disappointed when I tell them I exercised more, ate smaller portions and made my own food. Folks want a story about a magic pill. They simply don’t want to know solutions that a 5-year-old could tell you. In this scenario, you have a defect and any developer could tell you that you don’t just fix the issue, but you fix the root cause. But I have done proper root cause analysis a tiny number of times in a 15-year career around software development [Mostly around times around defects which resulted in LARGE financial loss for the company!]. We all know we should do it, but no one takes the time to do it properly.

An Update..

I have updated my research project page! Take a peek :)

People are strange...

As I am tending to do over the last few weeks, there is one part of the week 6 readings I want to place my focus. 

Before we do that, as a second-year student, one of the clear advantages we have already encountered a lot of the seminal papers in the areas we are working. Last year I used to HATE when a second year said in class, "oh yea, we did that last year" and the lecturer would skip over it. So Im trying to avoid doing that. So many of the papers referenced in this week's readings have been covered in modules we have already completed, which makes it easier for us second years to grasp. We have already spent 6 weeks trying to get our heads wrapped around bloody structuration theory!!! So for that reason, I'm not going to talk about the classic Curtis, Krasner and Iscoe paper [one of my favourites from the course so far, for what it's worth]. My project shall indeed use it, as I do love their core point that we should not see requirements as things to be dragged from users heads. But that often requirements don't exist and have to be constructed from various human interactions.

In the Fiction of Methodological Development paper, Nandhakumar and Avison say,

"There is one particular part of the "The development process therefore, far from being a life-cycle process, involves complex human actions and interactions. As Orlikowski and Robey (1991) claim, developers ``do not act in a vacuum'', but are influenced by various issues in the organizational context, such as their knowledge about methodologies and implicit social norms, the resources available to them and the organizational form and culture. Drawing on Giddens' (1984) structuration theory, we may see the development process in terms of cycles of interactions between developers' actions and social context in which the developers draw on their knowledge about organizational context and methodologies. Activities of the EIS team members, in turn, helped to reinforce this social context"

 I think this raises critical points which are easy to miss. We often obsess with methodologies and process or indeed with technology "we need to port this to the cloud, and all our problems will go away". As their study finds, is that it's all about people. A team of people who are people shy introverts will often be doing things very differently day to day than another team of extroverts shooting nerf guns at each other! These are extreme examples, but you find these kinds of teams in every large company. I once managed a team of developers in Kiev, and if micro-managed their work was excellent. But if left to their own devices, their work was sloppy and sub-standard. They needed to be told what to do at every level, and that was what they were used to. Contrast that with the team I worked with in Cape Town, South Africa. If I tried to micro-manage them I would have serious problems. They are much louder and stronger personalities. I gave them requirements and deadlines, and from then by and large got updates in morning stand-ups and at no other time.

Jim Morrison said it best, "people are strange.."! That is what is important to remember in all of this. You adapt process around all processes, but especially development to what team you have. One team will do Kanban, with many tiny tasks in an ever flowing board. With another team you have a small number of bigger tasks, reviewed monthly or something. It all comes back to the people! You want to look at the people on your team [& who your customers are, and who they have], and how you get the best from them. You adapt to your people and environment. I would not go full on Myers-Briggs with specific labels. But I cant argue with their general point, and how it drives who will work best with who [all things being equal].

In our Iona case study it seems to be clear [to me!] that as they became bigger and more successful, they lost some of that fun start-up culture. It was not fun anymore. But the other side of that start-up culture is that often bad processes often become embedded and at times you will get a hero mentality, of people and teams taking on huge burdens in an effort to be seen as "the best", and that also looks like it happened at Iona. That is where you need to step back at times and look at what you are doing, and why you are doing it. You need to examine who you have, if they are doing their best and if they are happy [and if not, how can you make things better for them and your customers. This is tied to the points above. Its about the social context of folks actions. At times its VERY important that a leader takes a step away. The leader needs to look at things being in place for the sole reason that person x did it this way once, and this becomes the process everyone else must follow. No knows why we do it, or why we expect that its slow or manual. But every time we do this slow manual process put into place by mister x it gets reinforced [in the Iona case, its the stupid long hours to support products!]

SDLC, Waterfall versus the rest of the world!

The readings we had this week were very interesting. They are all pretty old by computer standards, [which is depressing, in that one was published the year I left school]! You look at them all and the universal theme is that how teams were doing the software development lifecycle is bad. You scratch below the surface, and you see they are all operating in a world of waterfall. In that sole subject area they are correct. But I have a problem, read on to learn why.

I have worked in a waterfall world. Put simply we have a big bang release every year. I worked for a games company. The game went to customers for Christmas, and we cut our master in November. So we developed code all year, and in the month before we cut our release we all worked 20 hours a day and 7 days a week to get things done [not unlike our friends in the soul of a new machine book IMHO!]. When we had an issue we went back to the start, and it was an utter nightmare. I think back and I'm amazed how we got things done, and Im also amazed as how terrible our software really was at the time. But we got away with it, as people loved it, and also we had a dedicated team of work-a-holics who fixed issues quickly.

So in this waterfall world the Software Development Lifecycle [hereafter SDLC] is indeed pretty rubbish. As a simple example, you design something, you write many months code [maybe several thousand[s] of lines], and then in test you find an issue[s]. Of course this is stupid and terrible, as the bug could be anywhere and could take a long time to find and fix [think finding a needle in a stack of needles!]. This takes time, and is very costly in terms of human time, build and deploy time and time, this is time not spent adding other value to product, and basically costs money on any metric you care for.

This is why many companies have moved to an agile world [which we speak about later in the course]. It is why the software world is slowly moving to micro-services and continuous delivery. In this world, the SDLC is fantastic.

Let's take an imaginary payments service, from an online company. In a Waterfall world you will have a massive service doing all kinds of payments, incoming and outgoing . This old school payments service could be dependent on other services or indeed other services may be dependent on it. So you can break other stuff, and other stuff can break you. This service does many things, so most of it can work fine, and one small bit can cause havoc. You would likely build and release it to live every month, quarter, year or something like that. If it's broken you won't send or receive any payments. Your company is dead and losing many euro every minute, in terms of hard cash and customers going somewhere else.

In the modern world, you won't have a single payments service, you will have 20 [or so] 'micro services'. Using last week's reading, your development team will have spent time untangling the payments ball of wax. Each of these micro services can be built on their own. They should work on their own. So ifor another easy example, 'Payments.Outgoing.CreditCard.Visa' is broken and therefore, your automated outgoing payments to visa may not work, 'Payments.Incoming.CreditCard.Visa' should still work and is totally unaffected, you folks paying you with Visa works fine. Not to forget that 'payments.*.mastercard' was never affected.

In this world, the issue is very localised. You should know the exact problem and location quickly. Therefore you should be able to identify who is needed to examine, code and test a fix. You should not require 20 people in a room! It should not take months. Its quick and easy [..most of the time!] :)

So my personal issue with this week's readings is that, they are outdated. When the papers were written, the issues were very real, Now, these issues don't exist in the modern world as even companies I know of who release in a waterfall manner, develop behind the scenes in an agile world and want to break up and untangle their services. [But that being said, these papers are good for academic study such as ours, in class!].

On the Big Ball of Mud, a reading on the paper by Foote and Yodder

I found the Foote and Yodder paper "Big Ball of Mud" most interesting. I have spent much of my working career firstly, testing said balls of mud, then managing the building and deployment of the mud. I'm now a product manager, making sure we no longer build mud :)

For reasons of financial necessity or just disorganisation a lot of development teams have short sighted goals, where any kind of working delivery is viewed as a far better outcome than taking longer to make a more reliable or easier to maintain solution. By taking this approach, these short-sighted teams will build up technical debt. That is, they will get their working delivery on a high-interest lease program, with a large payment due in the future as their system is difficult to  expand and upgrade.

Think of an ERP system. In one of our previous modules, we were told a number of large investors used a company announcing the roll out of an ERP system as a merger and acquisition strategy. These investors considered ERP systems so complex & expensive a number of companies investing into getting them in place will run into problems and cripple the company. You often see and hear of companies having these systems in place, and they get someone to customise them, to suit their practices & desires. This makes this easier day to day, which is good. On the flip side this is a fast track to ball of mudland!! I managed an instance of SalesForce [a CRM system] for a large finance company. Their SalesForce instance was *very* heavily customised. What this meant was that when SalesForce did their system wide upgrades 3 times a year our system fell apart, and once took three weeks to fix. When I left that company SalesForce were about to retire two features we were heavily dependent on. We had never taken the time to upgrade them [3 years after they first said they would replace them]. Management simply put the update on the long finger, and left them alone as we had spent so much time and money customising the system. That it was deemed too expensive, it did not add any value. So then, down the road, they were faced with a major upgrade project, with a gun to their heads, and half the time and necessary resources available. Insert more mud here!!

I do like the focus, so far on this course, in thinking about how a product manager would think. As a product manager you need to think about getting your "thing" out the door. But you also must have an eye on medium and longer term goals. So there is very little benefit in getting a version 1 out there, if its unstable or impossible to maintain, as by the time you deliver it, plans are well underway to your next set of enhancements. Consider this article, from an industry blog I often read. This article describes how you break down complex items into easy to digest user stories which your development teams can then consume. They can build their solutions accordingly. But it is very much implied [and I would reinforce in person], that in the example on that website example, I want the ability to later add currencies, change prices etc. You build your system with that in mind from day one, it takes longer out the door, yes - but later enhancements are easy [as is testing and eventual refactor & redesign]

Iona..

I'm going to enjoy reading & watching the Iona case studies. Not only am I old enough to remember when Iona had massive hype as "the next big thing" and one of the leading lights of the Irish tech scene.

I also work for the current incarnation of what was a company founded when Iona was broken up. Cape Clear software was a spin-off company from Iona, and was formed in 1999. It was based in Ireland and Californa. Cape Clear became one of the world's leading providers of enterprise service bus software. In 2008 Workday Inc bought Cape Clear, and what was Cape Clear became Workday Europe. Read this interesting blog post, posted by Annrai O'Toole in 2013. You will notice the name, as Annrai is listed in this week's case study as an Iona co-founder, and is now CTO of Workday Europe. The blog covers the first 5 years of the partnership between Cape Clear and workday.

Working on the move..

I was at the rugby in London over the weekend. The flight was delayed on my return. What is brilliant is that I don't really miss much in terms of work.

I have full email and calendar access from my phone here. I can chat with the various teams in work with on Slack. I was able to dial into one meeting from the Gatwick express train (we had folks on the call from 3 different countries). This was made easier as we use a phone service with local numbers in each country. So I'm 2 hours late to the actual office,  but thanks to some good technology solutions the world keeps turning & no one is stressed :)

Not only that,  my multi tasking extends to doing this blog post for college on my phone,  with the blogger app!

Fieldwork Research, Ticketmaster

For my research, I looked at the ticket selling site, Ticketmaster. In days of old when any big event went onsale there were invariably backend issues, resulting in front end timeouts or full-on crashes. A couple of weeks ago, U2 put tickets for Dublin concerts on sale, and TicketMaster unveiled a new process to prevent such issues reoccuring.

Im going to look at this progression from old system, to the new system with the help of two different protocols. First, I am going to do a 5 whys on the process of site going down and what could be done around that. Second, I'm try the site, and be my own customer.

Ask - 5 Whys

• Ask why in response to 5 consecutive answers
• Ticketmaster crashed under high load
• Large amounts of users overload web server and backend systems
• Ticketmaster front end systems flood the backend with more users than it can handle
• Web servers handling high user load is very easy, but one point of failure in backend would show a failure in front end
• Backend failures are often costly, difficult and time consuming, they also take the entire site down, to overall lost revenue is extreme, and not just limited to one set of concerts :)

Oops, you need to start again - and by that stage you know the concert will be sold out :)

Ticketmaster's solution is a clever one, in times of high load they have a queueing system. I could imagine a thread based queuing system. The system is designed to handle a specific number of simultaneous transactions, and above that you simply go into a number of queues, and each person is addressed in turn.

Still not perfect, but waiting in line for a chance to buy a ticket is far better user experience than the site full on crashing :)

Try - Be your customers

• Outline typical customer experiences

Previous customer experience was that in the event of a busy concert the website eventually would grind to a halt, and it was a matter of when and not if the site would crash. Knowing how these kinds of backend systems work, there is likely to have been at least one failure point.  I have seen many systems where one part of the system does not perform under load, and when a specific point is reached, it either slowed down or crashed full stop. I worked on one system where when tested in isolation each end point was perfect under load of tens of thousands of users. But when together on the same set of servers they would crash with 100 users doing regular actions. The items put each other under stress, and importantly put their host machine under stress.

Ah, you nearly got to the end, but our payment gateway is down, sorry - start again and hope for the best :)

Under this new system at ticketmaster, they are clearly regulating what customers reach the critical points of the backend systems. So at a basic level, they have a funnel. So they have a trickle of users reaching the choke points in the backend. So their site stays up, and is performant for users buying tickets for the busy concert, and also importantly, other users of the site.

Another good idea, in terms of keeping the site up, was that for the U2 concert one had many ticket options. By having many different classes of ticket, everyone was not hitting the same end point in the backend, you had ordinary tickets, student tickets, VIP tickets, Premium tickets, I cant believe its not butter tickets, the list goes on. This means you have 5 or 6 main queues and not one epic queues. This is good traffic management, if a little confusing for the end user.

Activity Checklist

Activity theory is in effect a way in which you, as a product manager, can build a checklist by which you can analyse and break down complex issues and problems into different sections. It is important in that it mixes what actions are computer controlled and which actions are driven by human interaction.

"The five basic principles of Activity Theory:

1. Object-orientedness
2. Hierarchical structure of human activity
3. Internalisation and externalisation
4. Mediation
5. Development"

We can break down these activities to analyse an existing system, or indeed to start to design a new system.

It makes me think of a book I was given as a gift when I was first promoted to the role of product manager. That book is called "The checklist manifesto". The book breaks down how the most complex activities can be made more easily repeatable and safer by making people who are involved follow a checklist. It shows examples how mortality rates around medical procedures fell dramatically when staff were made follow a checklist, even around simple things like ensuring the correct person was being operated on, the correct procedures being performed and so on. I had occasion to see this in action this summer, as I broke both my arms. When I went into the first surgery, they had down that my left wrist was to have pins and plates inserted into it [this was wrong, my right wrist was the broken one!!!]. This was only caught in pre-operation checks, as I was about to be put under an anesthetic. You can draw a correct parallel with an IT system. You begin with simple questions like "what problem are we trying to solve" and you then ask the questions which logically follow on from that. You can easily make this into a checklist or set questions, and thus follow it for all changes.

The Soul of a New Machine

We had assigned reading for this class of The Soul of a New Machine. I cheated on this a tiny bit, in that I was away last week, and the book I had with me was not brilliant [to say the least]. So I decided to be good, and get this one and check it out. I was sitting in a bar in Lisbon, Portugal. I launched my Kindle, and found the book in 2 minutes, cost was only €4.50, and 2 minutes later I had the book. On its own this is a brilliant use case for the kindle and its Whisper sync functionality. I can get a book basically anywhere on earth, in seconds. You cannot but be amazed and admire that, regardless of what you think of other aspects of Amazon's business practices.

On the subject of the book, many wont have read it yet. Without giving anything away, its interesting that at the very start of my career [a long 16 or 17 years ago] I worked in a couple of software companies with a culture and environment a lot like what the book describes. Overall at the time I did not mind, but I look back and think that I learned a lot from those experiences, but many of those learnings are things not to do again and places where we were disgustingly inefficient in terms of planning or process. I think many of the people in the book would say the same thing.

Anyway, more on that whole subject in a few weeks :)

First post..

This is a blog for the Managing Design and Development class. We are doing this class as part of the MSc in iBusiness class at the Smurfit school of business. I am in the second year of this class, and this is my seventh module.

By day, I am a senior product manager with a large cloud based software company. My focus with that company is  on their internal monitoring and development tools. I have around 15 or 16 years experience working with development teams, from a range of different points of view and perspectives. 

The blog title also refers to the fact that during this semester I shall become a dad for the first time. It's therefore inevitable that the odd baby reference shall creep in here. Indeed, we have already have a planning meeting, complete with post-it notes in different swim lanes, as you would plan a software project :)