Book Review : Intercom on Product Management

Intercom on Product Management

So this is a book I picked from Mathias Meyers 2015 Reading List, which is a fantastic resource for anyone who is wanting to find some inspiration on some books to read. It's a mixture of technical software books and also fiction that he read. This one really stood out to me, interesting topic and a very interesting source. Intercom are a very interesting company with a great product, they have offices in Dublin and a very active blog which is a good read so this definitely grabbed my attention.

Also its FREE, hella free, and that's pretty awesome. It's 60 pages as well so it's not a huge investment of time either so I think it's a great one to pick up. So go do that

I'm not a product manager but in a company who is making the transition to a product company. Whilst I'm not a product manager I feel an attachment to our product and what we offer. I think that's pretty common with a lot of Engineers and most of us will be engaging in conversations with your product manager a lot. You should be. You are immersed in the product a lot of the time so in some ways you could be one of the more prolific users. I think as a software developer this is a very valuable read and really nice to be able to try and transplant your view on software deliver to that of your colleague in a different role. One of the really important pieces about being in a cross-functional team is understanding everyone's goals.

It's an interesting place to be somewhere that's gone from a custom software shop to a product company as a lot of the thoughts and documents (like this one) are from companies that started off as a product company. With that in mind I don't think it's always relevant to the day to day challenges we see but this book does a really good job of trying to lift itself up and talk in general terms about trends and principals which is always the most useful.

I won't go into too much detail. It's a short book but one that is focussed and I think to me there are a couple of big takeaways

Engage with your Customer

This is the number one take away and from a company that has their business based around this concept I don't think that's a surprise but it's one that makes perfect sense.

To me, one of the biggest trends of last year was companies talking about their A/B testing and it's infrastructure. LinkedIn had a number of posts on their blog about it and I think monitoring behaviour and attempting to gain insights is a huge thing at the minute. Intercom certainly don't speak against that practice but also talk about direct customer engagement too.

Find out what people are using. Use that to drive your roadmap. Let the numbers guide you but don't be a slave to them. They had a blog post on that topic as well. I think the biggest thing to me is if you have data it should be shared or available to cross functional team.

Be Ruthless about what's valuable

Couple of quotes that really stuck out for me

There is no pride in having a “big” product with lots of features, only a highly engaged one. The more surface area your product has, the more important it is that you chase engagement and learn from your mistakes

and

If you want a well defined product, you must be comfortable killing features.

The concept of killing features and constantly interrogating the value delivered opens up an avenue of work that's normally removed from the development team. We're closest to the release of a new feature but the care and feeding of those features or more the choice of which to feed is probably not part of our day to day.

Removing features from software sounds so counter-intuitive. We're conditioned to believe that we should always be adding new features but the argument here seems to be not only regarding engagement but also real estate and sprawl. We probably only have so much ground that we can use to be meaningful before the product can become unwieldy and as such we should look at that land and make sure that those features haven't become a diminishing return.

Cutting back features is helpful. Maybe the best metaphor is pruning a plant. It gives us the ability to shape, remove deadwood or increase yield.

Nothing is really free right...

So this is no exception. There's a pretty substantial undertone in the book that if you want to be successful and having engaged users with successful features you need to engage with customers in app. Coincidentally ;) that's what Intercom do for their business...

That said it's not too obtrusive and I think the overall message is pretty sound. I think the fact that they are eating their own dog food in terms of contextual endorsements shows that they really believe it.

Summary

It's free. It's not obscenely long. It's definitely worth a read even just to clarify you on what the end goal of day to day coding really is and that's keeping the customers engaged and happy. Would really love to know what anyone with a product management background thought of it.

I found it challenged a lot of things that I always held dear like "Delivering Software is the most important thing" to instead try and focus on the value that's being delivered. Sounds simple but when you are closer to the execution sometimes you can lose focus on that.

The Software Craftsman - Book Review

The Software Craftsman is the first book I have read this year as part of my resolutions, and truth be told this book is the reason behind those resolutions. That's how much this book resonated with me. Sandro Mancuso's book is practically a call to arms for developers to care about their craft and plan a career around developing knowledge and skill rather than purely titles or salary increments.

Bob Martins introduction compares the book to Roberta Flack song "Killing Me Softly" which is about a singer who sings a song that stops her dead in her tracks because it's like he knows her inner most thoughts. He mentions that this book is that for programmers. I think that speaks volumes. This isn't just a collection of war stories from a grizzled experienced developer but it's the basis of a blueprint for young developers to follow and one that's spawned a movement that is still developing and growing across the world.

The book itself is split into 2 very distinct sections. One on "Attitude and Ideology" and the other on "Full Transformation" which discusses the fallacies in Job Descriptions and Interviews and the challenges of dealing with morale problems. I found myself aghast at the frankness of the author as he talks about the challenges of clock watching developers and other topics that not many people talk about but most of us deal with. Other topics which get touched on are terrible interviews, terrible job descriptions, reluctance to change, intellectual bullying or terrorism by individuals and how to counter it and many more.

It would take too long to go deep into everything this book talks about and achieves so I'll just try and hit the hight points to me and recommend that you take the time to pick it up yourself.

Caring for your work. Pragmatism.

The running theme of this book is about embracing and owning your career. It's about not thinking about the next two years but more where you think you want to develop yourself long-term and looking to realise that through challenging yourself to make progress towards that. It talks about moving jobs to round out experience in different technologies or working environments or to work with different mentors with differing styles.

The book attempts to provide a core set of values or manifesto that are not linked to working processes or technologies. Essentially to me the message is keep an open mind, learn and adapt and never tire of looking for ways to improve your ability.

Always improving yourself or Owning your Career

This talks about the ways to keep your skills sharp but also for taking the responsibility to do that in your own time. I love where I work, we have access to many resources to learn and also the ability for training and taking time out of our working days to learn new things. I cannot stress how lucky I feel to be able to do that. I also know from personal experience and also from interviewing external candidates that it's very easy to get into a very difficult situation were the work is dry and you are not encouraged to really divert your attention from the mechanical execution processes that are expected of you. If you feel like you might be in a similar place to that and want to find a way to get out of it then I honestly think this book has some direction (also check out this really nice blog post from StackExchange). This book has practical advice including book reviews and a way to understand which books are going to add the most value. It references Kata's, a new concept to me, as a way of improving or learning new languages. The overall message is strong though, if this is important to you then make time and get yourself out of your comfort zone.

Culture of Learning and Driving Technical Change

Two of the hardest things to do within an organization. Fostering a culture of learning and bringing other employees along with you is tackled with such gusto that it really does make
you believe it's possible. That's something that's very close to my heart and again the strength of conviction in this book makes you want to re-up your efforts. The important point that's
made is do it for yourself and be open to talk to people about it. You'll find like minded people will be attracted to join in. Trying to enforce adoption isn't going to work. It removes
value from the group if people are there because they have to be. Recently in work as well as us getting the technical blog up and running again there has been a big take up in
brown bag sessions and people wanting to talk at them. I had hoped to start a book club this year but instead I'm going to take the advice of this book and just talk the back legs of anyone
who gets near me about things I've read about or found interesting and encourage them.

Any Negatives?

One thing I have found difficult to ratify with myself is the description or perception of management and managers. Initially on reading the book I felt it was definitely a negative slant on it, now I think with time it seems like it's more a statement that the jobs and career paths are drastically different.
I don't think the intention was to disparage the role of a technical manager, but I'm loath to attempt to speak for the writer at this time. There are very few references to the potentially positive impacts that technical management can bring and most of the 'management' value that is spoken about I think is product management organizing a backlog for the engineers to execute against. I personally believe that some of the things being discussed around enabling growth and building welcoming cultures with a focus on learning can also be driven from a management position, but then I was always
going to say that right :). The book talks a lot about how developers can communicate with management and others to let them know the importance and value of the craftsman process and
techniques but why can technical managers not also be part of that culture and learn too.

We continually talk about the days of command and control traditional management being dead
but don't seem to value the new approaches around coaching, enablement, insulation and advocacy. Sometimes I feel like the worth of that function is under-appreciated and all that is wanted these days is the much fabled 'servitude management' and essentially for managers to just get out of the bloody way. The message and principles of this book are too important to simply reside within the development organization and to me it's similar to a single department 'doing agile' because it will be met with confusion by other stakeholders.

Summary

That said I think this is an important book for any developer especially anyone starting out on the road of their career. Sandro references some texts which he believes to transcend individual technology choices and hit to the very heart of what it is to be an excellent software developer. I think his own book belongs in that group. I really can't stress that enough I think this book is up there with "Clean Code" and others as books which I wish I had read sooner.

Things I've taken from this Book

- It inspired me to pick up the blog and set the resolutions I did
- It's caused me to have a frank self-evaluation of my abilities and my career
- I had no knowledge of software kata's before having only really knowledge of the 'kanban flavour' (This Slide Deck describes it this is an excellent link btw so if you have time well worth a visit)

New Years Resolutions 2016

So I've been shocking at this blog thing.  There's no escaping that but I made a decision last week that this year would be a year of me actually being a real community member as a software engineer. To try and keep me on the right track I decided to basically have some career resolutions but framed up nicely for the calendar year.

This isn't a full new year means new me type deal but rather just taking a few further steps to get out there and broaden my horizons. 

The last time I really engaged with the idea of the blog was when I was feeling pretty isolated working as a Buld Release Engineer and trying to foster a DevOps culture in the office. For a reasonable period of that time I was a singleton role in the office (with lovely colleagues in Boston of course) and I think that really led for me to try and reach out and talk to people. I was also absolutely head over heels in love with Chef (I still am sorry) and couldn't shut up about it. I think it accounts for like 90% of my stack overflow interactions as well.

I decided that hell I'm still pretty passionate about software engineering and a lot of the people and technologies I work with so with that in mind lets get straight into the resolutions

The Resolutions

1) Blog at least 12 times

For someone with none in 3 years this may seem ambitious but I have come to realise that the career move I have made into Engineering management in the past year is of interest to people especially because I know I personally have struggled with many parts of that move and not being that individual technical contributor in the same way.  Also I'm managing a specialist team in an area I have little experience  (UI Development) and there my crutch of having exposure to technologies and challenges isn't there that can be quite scary and exposing like when you forgot your towel and need to dash from the bathroom to get one knowing full well the curtains aren't closed (quick shout out to anyone who has copped such an eyeful whilst walking in Hillsborough park)

I don't think those struggles are uncommon but there's a lot that can be said on the role of a manager whilst wanting to have autonomous empowered teams.

Also as I was part of the effort to found a technology blog at work this year it's a little shabby that I don't really have a personal blog.

2) Read 12 books related to my job

This effort has been partly inspired by a book I'm currently reading called The Software Craftsman by Sandro Mancuso 

I am lucky enough to work somewhere that has a subscription to safari online so access to a lot of titles shouldn't be an issue. 

Some of the books may have a management or soft skills slant as well but the aim is 12 books with some relevance to a career in software development.

I really want to introduce a book club in work this year so I'm hoping to start small and get a few colleagues interested in specific books.

Take 12 online courses

So there are so many excellent resources for free courses that this should be readily doable. 

Mainly I'll be looking to do something I've mo experience in rather than brushing up on anything currently. 

I have experience with a number of the providers including edx  (functional and saas) to pluralsight (not free but luckily my work has some accounts). This will probably be a mix of shorter technology specific courses to some more building block pieces like those from edx. 

I think there's a real embarrassment of riches when it comes to online courses at the minute so I'm going to me a concerted effort to fill my boots this year.

I'm quite weak on front end technologies so that's of particular interest. 

Make 12 contributions to the open source community

The hard one. I use a lot of open source software and yet my contribution back has been poor. I'm not alone on that front and I know there's a lot of people who like me are willing but maybe unsure as to where to start?

That's what I'm going to find the toughest but I'm going to try and use it as an opportunity to help out, support projects I like and also develop some of my own skills as I do it. For example I've written a few pet projects in go but I'm very much a newbie at it so I'm hoping to get to the point of being able to contribute to some go projects this year. It's unlikely that I'll get a chance to use it professionally this year so this seems like a win win scenario.

Hopefully no one that's seen my code is reading this as otherwise they may say the most noble contribution I can make is standing back and making a financial contribution ; )

Take part in 12 community events

So this is meet ups and conferences and tech talks and hackathons and all that goodness. I dabble a bit but not very often. I went to the Lead Dev Conference with a colleague (Blog post he wrote about it here) and was part of a resilience tech talk last year in Belfast. I keep circling local events and then making excuses not to go and that's pretty short sighted as normally when I do go I really enjoy hearing other people's war stories of using certain tools or facing certain issues.

Software can be quite an isolating place to work until you realise that there is a whole community of people who get excited about the same things.

Getting Started 

So if anyone has any suggestions on any of the above sections or would like to get involved too let me know. You can also catch me on Twitter on @DundrumMuscles 

I should also make a resolution to have a prettier blog as well