Being a part of an interview can be a daunting task. For some people it’s a painful experience, for others it’s a thrill. I remember being in interviews that I didn’t want to end, and in others where I felt like banging my head against the desk. Assuming the interview is going well, there’s this one question that I always like to bring up.
If I’m being interviewed I like to ask:
If I do everything right by you, and I am a top performer, where can I be in two years’ time?
I need to know what the strategic plan is for the company. I want to know what the growth opportunities are. Depending on the passion and the clarity of the response I can also draw other conclusions or come up with follow up questions.
The reverse is also true. When I conduct interviews (and I’ve done hundreds in my career so far) I like to ask:
If we do everything right by you, and we support your growth, where do you see yourself in two years’ time?
I have heard some amazing answers, ranging from: “I’ve left the country“, “I’m running my own company“, “I’m the best mobile developer in New Zealand“, all the way to “I have taken your job“.
If you decide to start asking this question in your interviews (whichever side of the table you’ll find yourself), I encourage you to follow up during your first and second performance reviews…
So why don’t you take a moment and ask yourself: if you are honest with yourself, where do you want to be in two years’ time? If you’re feeling brave, tweet me your response.
p.s. this is a good opportunity for me to recommend this book: The Manager’s Book of Questions by John Kador. It’s a fairly old book, but because it doesn’t focus on one particular technology, it asks various categories of questions (from icebreakers to competency), and it doesn’t seek provide the answers, I still find it very relevant.
The 6th instalment of the Wellington Android Meetup took place today. I decided not to write about the content (I wouldn’t do justice to the presenters, and the audience contributed so much content, that I’d surely forget to mention something important), instead I wish to write about just how “fragmented” Android is … in Wellington, New Zealand.
Four talks
We had four speakers. Two men: Matt and Lucas; and two women: Jayna and Leonie. That was not planned, it just happened.
We had two fairly technical presentations that encouraged us to improve our technical chops and solve problems in more beautiful ways, and two that challenged us to think about what we like, what brings us joy, and what we are prepared to do from the goodness of our hearts.
People in the room
I glanced around the room and I was so happy to see how diverse it was. So many skin colours, genders, ethnicities, and ages!
In the room we had students, unemployed folks, business owners, developers, designers, testers, and even Windows Phone developers! There were people working for startups and people working for organisations with 500+ employees!
There were women. Not just sitting on chairs but engaging in the discussions. Driving them and asking the tough questions. Challenging the speakers and the audience. Recommending better ways to do things. As it should be!
I bring this up because I think back of where we started. I looked at some old photos I took and I struggle to find the women. I looked at the GDG Wellington reports I sent, and I blush seeing a mere two women attending one of the early sessions! Today, almost 20% of the audience were women!
But we are not stopping here. Tonight Lucas announced that we are planning a GDG Dev Fest W. The plan is to create a safe place for an evening, a day, or a weekend, where women can come and learn about technology without fearing that they may get laughed at, looked at in a condescending way, interrupted or ignored. Get in touch with Lucas or with myself if you want to help.
Fragmented
The Android community in Wellington is fragmented in the best possible way. This diversity makes the meetings more interesting, the points of view more diverse and more relevant.
I was the proud host of tonight’s gathering. It this kind of fragmentation that keeps me going, that motivates me to try harder, that makes me proud to be a small part of this incredible community. Our group now has more than 200 members, so I am hopeful that we have not seen the best of what this incredible bunch of people have to offer!
It’s true. The Android developer community in Wellington is strong and mature, if tonight’s first Android Meetup is anything to go by.
The setup
Android Meetup Attendees
Just over 30 people took part in the first (of hopefully many more to come) Meetup that I was proud to facilitate and host together with the rest of the Trade Me Mobile team at our Market Lane office. We will try to make sure this becomes a regular event, especially now that the GDG Wellington was created.
The turn out was fantastic (we had to supplement the available slots at the last-minute). The show of hands confirmed that the majority of attendees were developers but we also had designers, testers and business folk. This diversity definitely helped during the Q&A sessions…
The talks
The theme of the evening was Material Design and the agenda was simple. I gave a quick intro, then we kicked off properly with a presentation by Matthew Shearer (our Lead Android developer) about the challenges that we face at Trade Me when tacking Material Design in our app, followed by an interesting Q&A, then the spotlight was given to Glenn Parker (Xero) who showed off a few ideas/early mocks for their product. Other people in the room mentioned that Material Design was high up on their TODO list but they just haven’t gotten around to it.
The evening continued with food and drinks followed by an open discussion around the future of this group.
Where to from here?
We are very keen for this event to not be owned by one organisation. Instead, we’ll aim to put in place a roster so that other teams around town can host it and offer more diversity not just in terms of venues but also in terms of hours. We even floated the idea of doing it over lunch sometime to cater for those with young kids or who have engagements in the evenings…
Happiness Survey
As expected, the attendees behaved really well and communicated freely. There was no awkward job/hiring talk, nor any immature comments of any kind.
Toward the end of the event we brainstormed a few ideas for future sessions. We’ll vote on the group and we will decide what we will talk about next time (late January or early February). As this picture shows, people found the event valuable for the time they invested (2 hours) so I will call it a success!
Despite being a collection of “Rands in Repose” posts, this book is surprisingly readable. I can definitely see how a senior developer, an HR manager, and a team Leader (uppercase “L” is not a typo) would benefit from skimming this book over one weekend.
Bonus: You can learn a couple of social games while reading this book: Werewolf, and Back Alley Bridge.
A bunch of people that push each other forward and work together for a common goal form a team. A number of people who work for the same organisation but have individual goals belong to a group. One of the biggest differences between a team and a group is that a team’s achievements always outweighs the sum of all the individuals’ accomplishments.
To better explain my point of view, I will break down my definition of a successful team into the categories below and close with what I believe the manager’s role should be.
Motivation: Purpose, Accountability, and Goals
People in a group are very likely to be sold a goal. Depending on their professionalism, they will push themselves to achieve great outcomes and they will strive to be honest. Any failures or imperfections are forgettable and are perceived to be short-term. Accountability applies at personal level. In this context, the motivation for an individual is most often extrinsic.
In a team, the goals are set together through discussions, planning, and by sharing a common definition of success. The team has personality. Since the goal is shared, they push each other forward and hold each other accountable. Due to the fact that they collaborate closely they often end up raising the bar of expectations for each other in order to deliver better results at both personal and team level. Team players are intrinsically motivated.
Collaboration and Roles
In a group, individuals are less likely to contribute to other skills
In a work group, people share information, they are respectful with one another, and sometimes even behave in a formal way. Meetings sometimes turn into status reporting. Peoples’ ideas don’t always get challenged or augmented. There’s hardly ever any work done outside one’s area of expertise. The skills overlap is kept to a minimum, almost as a sign of respect. Personal development is determined by one’s own desire to better themselves rather than as a need to fill a gap. A designer is always a designer and a tester is always a tester. The Gantt1 chart for how a project runs is clear-cut. Task B always follows task A and never comes after task C.
In a team, individuals tend to push their peers forward
In a team, the collaboration is not just close, but from the outside it may even look chaotic. There is energy and people often venture beyond the limit of their skill. Developers and testers may end up sketching design approaches. Designers may roll up their sleeves and help with testing. Product owners will join the designers in user testing. Personal development is often done in a way that completes the collective knowledge. A tester may learn to use prototyping tools, while a designer may learn how to work with development tools. Each person may wear the hat of any of the other team mates and may jump in when their help is required. In a Team, tasks A,B, and C may take place at the same time and make a project manager’s life a living hell.
The Manager’s role
In a work group, the manager is almost a dictator (sets the goals, measures progress, and is the only one who can push a member’s limits). In a team, the manager is merely a guide and a facilitator.
All teams start off as a group. It’s a manager’s job to create an environment where people:
feel safe
speak freely
are comfortable with themselves and can be genuine
so that they can discover each other’s strengths, accept the weaknesses, and, over time, build trust.
1 Disclosure: I really don’t believe in Gantt charts.
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.
Provide context
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”
Take questions
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.
The Product Roadmap is like the north star. The same way a sail boat is guided by a trustworthy, never changing light source, the Product Roadmap is there to give a team direction and comfort that they are moving in the right direction.
The goal
The goal is to get the team to be intrinsically motivated about the Product Roadmap. I’m making the assumption that if you’re reading this post you probably agree that selling a roadmap to the development team is a difficult undertaking.
In order to be able to provide direction and comfort, the Roadmap has to have the team’s buy in. In the remainder of this post I will describe the way I believe a team should be approaching the definition of a successful Roadmap.
The actors
The teams are made of a number of skills. Some teams can have just two tiers (or just one when the leadership is provided from whithin the team) while in larger organisations there can even be a structure such as the one below.
Product Manager
Ultimately responsible with the delivery of the product
Technical Lead
The technical go to person for the entire team (cross skill)
Team Leader
Responsible with the entirety of a skill (e.g. developers)
Team Member
BA, Designer, Developer, Tester, etc
In reality, the more tiers there are in a team the higher the risk that there will be voices that have not been heard or that certain individuals will end up not feeling represented. Later in the life of the product these are most likely to become the least motivated or the least engaged team members.
The approach
I believe that people’s motivation disappears when the Roadmap is enforced top down. Too much energy has to be spent on selling a roadmap epic as opposed to discussion the merit of that roadmap entry.
Instead, I suggest a bottom-up approach. I call this, the Pyramid of Trust. I will describe how this works by looking at a complex team structure. In a simpler situation, pyramid levels could simply be removed.
The Pyramid of Trust … is built from the ground up
Step 1 – Ask the team
Everyone takes part in this exercise. Allocate enough time to allow people to collect ideas and to have a couple of minutes to pitch them. There are no bad ideas at this point. Think of it almost as a brainstorming phase.
This first step is also the most important one, because this is where trust starts being built. Here are some guidelines on how to approach it:
Remind the team about the company values / mission / priorities
Ask them to suggest a limited number of ideas (no more than 3). These ideas must be good for the product, for the end user, and for the business
Once the team have spoken, it’s time for their leaders to contribute with their own proposals
Lastly, the Product Manager / Business Owner is going to present their own idea
Step 2 – Find the themes
Realistically there will be many ideas that the team simply won’t have time to build. Some ideas might just be plain bad. Other ideas might need resources that simply are not available. These are just a few reasons why in step two, the Team Leaders should get together with the Technical Lead and the Product Manager to:
group these ideas by theme
discard themes / ideas that are not suitable
Delegating or sharing this responsibility with the Team Leaders is beneficial because:
it gives comfort to the team members who know that they are represented in the selection process
teaches the Team Leaders about responsibility and pragmatism
is a healthy process that enables excellent technical proposals to survive the selection process
Step 3 – Isolate the Epics
It’s time for the Technical Lead and the Product Manager to make the final selection for the Epics that will make it into the Roadmap.
This is the step where emotion is put aside and the business and the technical skills get together to figure out the best ways forward. At the end of this step the Product Manager will have mandate from the development team to pitch a Roadmap to the business.
The Technical Lead will need to figure out ways to plug the holes in the team’s skills set, resource and prioritise appropriately, find training and upscaling opportunities. All these will help the team be as prepared as they can be when they come about implementing this Roadmap.
Step 4 – Pitch the finalised Roadmap
The Product Manager is now under pressure from the team to represent their ideas when pitching this Roadmap to the wider business or to the stakeholders. Compromises usually need to be made and not everything will work according to “plan”. The bright side to this approach though is that the Product Manager will have the confidence to speak on behalf of the team knowing that if their suggestions make it into the agreed Roadmap then the team are likely to be motivated and engaged as they are, in fact, co-owners of this Roadmap.
Conclusion and next steps
It’s important to remember that if an idea that was generated by a team member makes it into the final roadmap, this person should be involved in the phases to follow: exploration, research, strategy, implementation. This way credit is given where it’s due, the sense of ownership and belonging is reinforced and this becomes a good example for the roadmap sessions that will take place in the future…
A good idea would be to make the roadmap as visible as possible, in a way that does not use actual dates. The focus should be on sequence more than anything. I would suggest three monthly updates on progress. These would also serve as reminders of the common team purpose.
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.
Relevant background
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.
Crossroads
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.
Today’s turmoil
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:
Nothing
Keep reading (subscribe to the RSS feed)
Submit feedback via my Twitter account or by using the contact page
