I just read this book, and it was good. Not quite 5-stars good, but a good book nonetheless. A couple of chapters definitely stand out. The P&G analysis is fantastic, while the RIM introspection is hilarious. To be fair, it’s only funny because RIM stopped doing what the book is praising them for.
Here are a some of the notes I took (hopefully I don’t break copyright):
The minute you start analyzing and using consumer research, you drive all the creativity out of the product.
No good product was ever created from quantitative market research. Great products spring from the heart and soul of a great designer, unencumbered by committees, processes, or analyses.
Even as corporate leaders chase the vital, elusive spark of creativity, their organizations structures, processes, and norms extinguish it wherever it flares up.
Once knowledge has been pushed to a logical, arithmetic, or computational procedure, it can be reduced to software.
In most large business organizations, three forces converge to enshrine reliability and marginalize validity: the demand that an idea be proved before it is implemented, an aversion to bias, and the constraints of time.
An organization that engages exclusively in exploitation will ordinarily suffer from obsolescence.
Of the original Fortune 100 companies, published in 1955, only eleven are still on the list.
When a team can come together around a creative cause or a knotty problem, they want to come to work every day.
Laliberté (founder of Cirque du Soleil) had done no research to forecast the size of the market for his new form of circus. How could he? The market did not yet exist.
After a fair bit of research I decided to upgrade from my (basic) Kindle to the Kindle Paperwhite.
Kindle Paperwhite, 212ppi, 16-level gray scale
My previous Kindle was great. I didn’t feel like I needed the touch screen, and using the 5 directional button was fine. The main thing that I wished for was backlight. In the past, I would read on my Kindle during the day (especially outdoors), and on my iPad Mini at night. I’m hoping that now I can just use one device…
Why not the Voyage?
The Kindle Voyage looks great. I wish that the Paperwhite had physical page turn buttons, but I can’t justify spending $120 more for page-press sensors, 300ppi (rather than 212ppi for the Paperwhite), and adaptive light. I’ll just buy a dozen books with that money instead!
Why not read on the iPad Mini?
I could make up tons of reasons, but the truth is that I’m just not disciplined enough. I love my iPad Mini and I just get distracted by all the apps and things that I could be doing.
This year’s DevMob was different compared to all the previous DevMobs: there was tangible equilibrium between iOS and Android, with both platforms showing maturity in terms of tools, design metaphors and developer attention.
This year, the swag was particularly nice (thanks to the Alphero team). The sponsors also contributed with very interesting talks, availability and engagement throughout the weekend, and a wicked Lego Death Star draw!
It was Wellington’s turn to host, and the chosen venue was Samuel Marsden Collegiate School. I give it the thumbs up: the food was great, there were plenty of rooms (and each had a projector), and we were even allowed to use the amphitheatre.
An evolving conference
Over the years, the conference evolved from being focused on iOS only, to sharing the spotlight between iOS and Android. This reflects the marketshare and the user base of the two platforms, and the ever growing number of developers interested in them. As one of the attendees who hasn’t missed a single iteration of this event, I’m happy to see such organic growth. It’s also good to see that the Microsoft folk have not given up, and keep attending these gatherings and contributing with incredibly useful insights (Azure being one such example).
My observation (potentially wrong) is that, year after year, the iOS talks have become a bit more abstract and more high level (a good incentive for me to return). At the same time, the audience has managed to keep some practical sessions on the board:
the show-and-tell sessions took a UI/UX spin
the demos contained products that are more and more polished (even though their authors consider them “rough”)
the live coding sessions were focused on concepts that a newcomer would probably struggle to fully understand, but would still find valuable
If a couple of years ago Julius was struggling2 to attract a handful of devs to take part in a blue-sky discussion, this year all the Android sessions had full rooms. Refreshingly, Google’s Material Design was at the centre of most discussions. The tools and libraries that people spoke about covered everything you can possibly think of: from analytics, networking, and storage, all the way to dependency injection and reactive programming.
I’m sad to see that Android developers still have to battle with basic things such as networking and resource loading. Michael Rueger from Xero gave a very good talk about the way their app tackles this area. I definitely think his talk should be shared at one of the next Wellington Android Development Meetups. While I’m talking about Xero, Glenn Parker was particularly active and even shared some interesting work they have underway. The Poweshop folks also contributed a great amount, confirming that Wellington is the place to be for Android developers. Not to be outdone, I shared as much as I could about the way that we do things at Trade Me.
No doubt about it, Android is a first class citizen and there’s some outstanding work being done in this space.
New in 2014
Back in 2009 when Jade Software launched DevMob (under the NZiDev moniker), the questions that people used to ask were along the lines of “how do I code, test, deploy, market my app, all at the same time?”. After just 5 editions, this question has transformed into “how do I run a distributed team? how do we collaborate with designers and testers? how do you manage an app’s backlog?”.
This year, I believe two themes were new to the stage: mobile development at scale, and an in-depth look at how to build mobile software. The gimmicky apps were pretty much absent, confirming that the mobile gold rush is well and truly over. For a change, Layton and Karl did not have to too many questions on how to build the next million dollar app.
Surprisingly, managing scale was probably one of the most talked about things this year. So much so that the group ended up creating a follow-up session after Luke Gumbley‘s “Backlog management / Feature planning” talk.
Team building, maintaining happiness, and dealing with ownership, all got tackled by the audience. The information flowed freely and openly thanks to the trusted environment that makes so many people return to this event year after year.
It wasn’t just the management side of things that was new this year. The sessions went deeper into the product life-cycle with topics such as API design, security, functional testing and mocking, UX, continuous integration and more.
I was happy to see large development houses (Cactuslab, JSA, Powershop, Trade Me, Vend, Xero, etc) share intimate details about how they tackle many aspects of the SDLC. The fact that non-coding topics permeated DevMob 2014 is encouraging for future iterations of this (un)conference.
Until next time
I missed out on the socialising that traditionally happens after the first day of the conference. I suppose that’s part of the deal when the event is hosted in one’s home town.
Many thanks to the hosts Nat, Janine, Tanya, Julie and everyone who contributed to making this event a success.
If I got anything wrong, or if you wish to pass any feedback, you can reach me on twitter.
Notes: 1 To learn more about (un)conferences you can visit Nat’s website, buy this Kindle book, or, my favourite option, just take part in one! 2 Julius is no longer struggling to attract new people to his talks. He now just needs to find a way to keep Sam awake. (Okay, this photo is cropped and you can’t see the 30 people sitting behind Sam, but it’s funny nonetheless.)
As a team leader, I sometimes find myself in a situation where I have to communicate a decision to my team. Here are some key principles that I a guide myself by when I do this.
Do it as early as it makes sense
Timing is one of the most important things to me. If my team find out about the “news” from somewhere else, their trust in me is likely to be shaken. I am there to look after them and to be their voice in the conversations that have an impact on them. The sooner I can do that, the more I can help them.
Give a quick rundown of what will be covered
At the beginning of the discussion I try to clarify what I will talk about. This provides not just structure, but it may prevent questions that would be answered anyway. At the same time, it enables everyone to write down any questions that I may have overlooked in my FAQ.
Ideally, the agenda should be sent with the meeting invite, but sometimes this is just not possible.
The reality is that not everyone reads their emails. If these emails contain business speak, are too lengthy, or come from a source that is too far away in the organisation, then it’s possible that people will just skim the message and not retain too much information.
The first part of the discussion should definitely include a quick recap of what has been going on, to bring everyone up to speed.
Stay honest, genuine, natural
I have seen so many people try to become somebody they are not during a presentation. Their pitch or tone would change. Their body language would be awkward. Their hand gestures would be unnatural. I try my hardest not to be one of these people.
Be yourself. Everyone else is taken.
I feel like being genuine helps reassure people that I am being honest. Even if the point of the meeting is to “sell” to the team something that they might not be too happy about, it’s still important that my tone is affiliative.
Give just the right amount of information
One very important aspect is finding the right balance between getting lost in the details (overwhelming the team with too much information) and being too vague about what the decision really entails.
Go through a FAQ
I try to think ahead of the questions that the team might have. Putting myself in their shoes is good for several reasons:
helps me prepare for the meeting
contributes to the decision of how much should be communicated
keeps me honest
prevents the piling up of answers such as “I don’t know”, and “I’ll get back to you”
I am a strong believer in the power of an honest “I don’t know”. Realistically, if the truth is that I don’t know, then anything else I would say is BS. I respect my team too much to reply with a political, or vague answer. It’s also very likely that the answer will be important to me too.
Thank and close
When closing, it’s important to remind people that the communication channel is still open. Some people are introverts, or simply not comfortable asking questions in front of their peers. Others prefer to communicate in writing. Their voices are equally important therefore they need to know that they can follow-up with me.
I need to put myself out there again. I am at crossroads with my career and I am hoping that writing about the decision making process and the context around it all will help me make the right decisions.
Instead of spending a lot of time and energy writing about my entire life, I will quickly summarise the last decade. Realistically, the last five years are the only relevant ones, so I will go into more detail as I approach current day.
2005 – 2009
About five years ago (2009), I was wrapping up my gig with Fronde Anywhere (a Mobile Banking & Finance pseudo-Start Up). I worked there between 2005 and 2009. My “consultant” title seemed to be the only generic term that could encapsulate all the roles I performed:
Software developer (Architecture, Mobile, Web, Systems Integration)
Trade Show presenter (e.g. CeBIT in Hannover)
RFP responder and integration partner
In New Zealand: ANZ, BNZ, KiwiBank, M-Co, Oracle, NZ Post, Telecom, Trade Me, Vodafone, Westpac
and abroad: BPI, Citi, Credit Agricole, Figaro, Sparkassen
Consultant and trainer (KiwiBank, CSC, Cap Gemini)
Marketing genius. Well not really, but I do take full credit for coming up with the Fronde name when Synergy International got rebranded
I soon realised that building software was just one facet of my technology persona. I also became aware that becoming involved with other businesses, and taking more product ownership was what I really wanted to do. Simply put, my view of my career and my priorities was somewhere along these lines:
short term: raise my profile as a Mobile technology person
medium term: build a popular Mobile solution that I would be proud of
long term: fill the gaps in my skills (leadership experience, design awareness, product mindedness)
The company I was working for was a good, comfortable place. However the challenges and the opportunities were not there so I had to make some changes. Without doubt, the most drastic change was starting Tmro. That was possible once I decided to reduce my work week from five to four days. I’ll dissect Tmro some other time, though…
2009 – …
The other change that I made was to take a job at Trade Me (2009). I joined as a back-end developer, but at every occasion I was pushing the Mobile agenda. My .NET adventure was short lived. The contractor that had been hired to build an iPhone app was constantly asking for my support which was formalised within a few months. His contract wrapped up and I became the solo developer. We released the first version of the Trade Me for iPhone app sometime around Guy Fawkes (2010).
Trade Me Mobile
The iPhone app grew fast; so fast that within just a few months the Trade Me Mobile Team was formed, when Sam joined me as the Mobile Team Tester. Design was a separate entity altogether (It took a few years until the designers joined the developers and the testers to form cross skilled squads/teams as part of the larger Mobile Tribe/Team). The Mobile Team expansion continued by hiring two more iOS developers. We agreed to keep the developer to tester ratio as close as possible to 3 to 1. Before we knew it, we were investigating the possibility of building an Android app to repeat the success of the iPhone app. We did it ourselves, while building another two apps for a satellite business. With four apps to support we finally hired our own Mobile designer. This happened just in time for the first vertical app: the Trade Me Property for iOS app and the beginning of our bravest app: the Trade Me for iPad app. Things escalated quickly: in just a couple of years the app portfolio was growing. So was the team. What was shrinking was the time I was spending building solutions. I found myself doing more and more product advocacy (breaking business rules for the sake of making the apps better), arguing for resources, writing project plans and proposals, taking part in strategy meetings, and most importantly, managing people. The dream was coming true: my medium and long term plans were going great.
I did not anticipate was was about to happen next, but in hindsight it’s easy to understand how building a product suite, growing and managing an entire team, and representing these both internally and externally was going to transform me into a Product person. My job title said “Team Leader” but, in my heart, I saw myself as a Product Gatekeeper with a clear understanding that keeping the team happy was the first step towards delivering delight to our members. My vision was thus formed:
Only a happy team can build products that people love.
Despite attending WWDC (twice), Google Developer events, Rails camps, Webstock, UI/UX conferences, Agile barcamps, and more, I was quickly drifting away from being just a software developer. My attention was constantly focused on the big picture rather than just the implementation detail. Most of the energy that used to be directed at learning new programming languages and development tools, was now invested in learning about what makes people tick and how to build products that people love.
The Mobile Team is now large (approaching 30) and is made of a bunch of incredible people. There are five leaders who are amazing at representing their colleagues. Our skills cover Android, Design, iOS, Test, and Windows Phone. We have outgrown Wellington (we are building a brand new team in Auckland). I sometimes wonder whether this is the largest Mobile Team in New Zealand. The products are more than just “relevant”. Our official strategy documents require that “mobile is ingrained” in everything we do and this requirement is justified by fantastic stats. There’s a problem though: I want more. Currently, I find myself waking up in the middle of the night, taking notes and jotting down thoughts and ideas for a new Product that I have had in the back of my head for around four years now.
Reboot completed. Logging in…
I probably won’t be able to talk about the details of this Product for a while. I will write about the challenges that I come across and the decisions that I plan on making starting with the next post…
Engage, or not
You can do a number of things, too:
Keep reading (subscribe to the RSS feed)
Submit feedback via my Twitter account or by using the contact page