A tool in balance coaching is the being and doing brainstorm. You brainstorm in two lists:
How am I being?
What am I doing?
The combination of the two feeds each other. E.g. you might say I’m “being proactive”, and then in doing you could list some ways to be proactive (e.g. “make a todo list at the start of each day and review it throughout”.).
I experimented with this in a group context last week and it worked pretty well. It went as follows.
Step 1: Define the end state. This needs to be something everyone can connect with. In this case, we saw great momentum on another platform in the meeting immediately before, so that was our starting point – where this team was also like that.
Step 2: Explain the concepts, with examples. People need to know what we’re doing.
Step 3: Individual brainstorm. Give people time to form their own ideas.
Step 4: Group brainstorm. Start working through everyone’s ideas and building on them. Remember there are no bad ideas in a brainstorming session! Try saying, “what I love about that idea is…” and building on it.
Step 5: Theme. Organize things into groups with 1-2 being tags, and a list of associated doings.
Step 6: Choose 1-2 themes. We each picked our top three and explained why, then chose the two most popular.
Step 7…8…9…: Experiment! Define some team experiments, try things, and iterate.
Accountable: People can have expectations of each other. This includes leadership.
Problem: Often these things result in mobile being a bit disconnected. Server side changes can break clients, and then mobile teams take the heat from users and leadership. This can lead to resentment, which makes accountability hard.
Accountability comes last, because it builds on everything else.
Being erratic undermines accountability – the chaos can always be blamed.
Lack of prioritisation undermines accountability – who is to say what was most important?
The less a team is automated, the more crucial but repetitive things can fall through the cracks.
If you want to hold someone accountable, assuming you’re not a sociopath, it needs to be clear what you’re holding them accountable for. But you individually holding people accountable doesn’t scale. In a healthy team, people will hold themselves accountable to their team.
I want to tell you a story about the worst manager I ever had. He hid deadlines, concealed missing deadlines, until eventually – unsurprisingly – the team and product was killed. One time I told him I was worried because we’d missed a deadline, and his response was “what deadline? There was no deadline.”
He made it impossible for other people to know what was going on, because he discouraged all communication that wasn’t to him. No-one on the team could really hold anyone else accountable because no-one knew what was going on. It was kind of farcical. The best way to know there was a deadline, is that when they happened the tech lead would disappear. One time he disappeared for three days to search for his cat.
Anyway we had this meeting, a post mortem, about why the team was a disaster and couldn’t ship anything. This tech lead made subtle digs at another guy on the team, and then said something super inappropriate and unfair to me. Everyone sat there in silence, and later people in that meeting told me how appalled they were. Another woman on the team said it was the first thing she had seen happen at work, that was blatantly happening to a woman because she was a woman.
My manager was in that meeting, but he didn’t handle it. I told him I was not OK with it, expecting him to do something about that. And he told me I should handle it myself.
This is probably what we should expect from a guy who dealt with deadlines by pretending they didn’t exist. Note: he didn’t say this about any of the minor complaints I’d had about this guy. Those he took under advisement. But when it was that inappropriate. It was on me.
Anyway, I got this dude 1:1 and I told him… well I told him everything he’d done to annoy me in the previous six months, why what he’d just done was completely messed up, and my conclusion: he had no leadership skills.
You might be surprised to learn this did not go well.
Now in my defence: I was right. This guy spent 4 months reinventing how to build an android app, and 8 months doing “UI polish” before shipping. The project he led was a disaster and when that was clear… he spent three days SEARCHING FOR HIS CAT.
Someone really needed to tell him that he was doing terribly at his job – but I was not the right person to do that. Firstly, I was a ball of rage. But secondly, I was trying to hold him accountable for something he hadn’t agreed to be accountable for – on a team that had no culture or norms of accountability. And I was starting not with a small thing, but with a major crisis thing.
This is not how you start building a culture of accountability. It’s not when you go “wow! I do not want to deal with that.” You start smaller.
First up: you hold yourself accountable.
Second: you encourage people to own up, and create space for them to do so.
Third: you create ways that team members can hold each other accountable.
How do you hold yourself accountable?
When we move into leadership, it’s really easy for our work to become less visible. The output is the team, no longer individual. Good leadership and management are both a lot of work, but often it’s nebulous and harder to surface. If our work is too visible, then it’s pretty likely we are not doing what we should be, or that we are taking too much credit for the work of the entire team.
Often we demonstrate accountability 1:1. We set 1:1 meetings, and we show up to them. We listen to what people say, and follow up on it – even if we can’t fix the problems right now. Now my work is more meta, I write an internal blog post every week where I share what I’ve spent time on and sometimes the less concrete things that I’m just thinking about. When I was a manager of ICs, I used to post my standup every day same as everyone else. Sometimes it’s just “1:1s” “code review”, but I find being transparent about how I spend my time goes a long way – even if my outputs are not as clear anymore.
How do you encourage people to hold themselves accountable?
You can’t make someone hold themselves accountable, but you can encourage accountability. I think standup is a great tool for this. I love written standups in Slack – because is doesn’t depend on everyone being around at once – my team is distributed across Europe, Asia, North and South America – but even for teams all in once place, people start at different times. Standup forces someone to start their day with some kind of intention about what they hope to achieve. As it’s written down, people can scroll back if things don’t go to plan or if they forget what they thought was important when they started in the morning.
You can invite accountability by asking people to share what they hope to get done over a given period – and giving them the opportunity to surface when things don’t go to plan. You can also invite accountability by asking questions before giving feedback or assigning blame. It’s much more powerful when someone owns up to what they need to do better, than when you tell them.
How can team members hold each other accountable?
Code review – done well – is such a good entry point into peer accountability. Because this is when people look at each other’s work, and ask hard questions, and give feedback. How do you get accountability outside of code review? A lot of that is about encouraging a non-judgemental space, where people can be open about what hasn’t gone to plan. There is nothing more toxic to a culture of accountability than blame – only when people feel like they can own up to each other will they be able to ask questions of each other without judgement or fear of seeming judgemental.
Clear on priorities: When you ask people what is most important and why, they can answer.
Problem: Leadership is often dominated by iOS users, so Android can feel like an afterthought.
If you ask a person on your team what your top priority is as a team, can they tell you?
Can they tell you why?
Can they talk about how their work fits into it?
…or if it doesn’t?
Do your actions, and the actions of leadership around you align with that top priority?
Do your team priorities align with your company priorities?
The challenge of team priorities is often not deciding what they should be, but deciding what should come first, and being consistent in your actions so that they align with that.
Let’s break it down.
What should your priorities be?
A sustainable product has both growth and retention.
Because mobile is growing and desktop is declining, your mobile experience (this includes the web, too, not just native) needs to effectively onboard new users.
The era of “there’s an app for that” is over. Of course there’s an app for that, but does that app merit the space it takes up on my phone?
The users who install your app on their device and use it every day are your engaged users. They’ve made it past onboarding, they’ve figured out what it’s for – how do you maintain that engagement?
Is there anything broken that might drive people away?
Different products have different priorities, but it’s important to consider both your new user experience and your existing user experience. Over time, to be sustainable, you have to balance both. If you onboard people into a bad experience and drive them away, you’ll never get them back. But you do need to focus on your onboarding experience in order to grow.
There are two apps I’ve abandoned For Cause. Nike Fuel and Duolingo. Note they are both gamification apps. The same thing happened on both of them – they lost my streak. The Nikefuel was a hardware failure, and Duolingo poor saving of state after an unexpected internet disconnection.
Actually another example of that is WordPress, years ago, before I worked at Automattic. I lost a blogpost on my iPad. I was taking notes during a talk, so there was no way to get it back. I stopped using the app to write and switched to the notes app (and later Simplenote).
People complain, a lot. Technology is fallible. But whatever your product, you need to understand what is your UX catastrophe. For a writing app, it’s content loss. For a gamification app, I would say it’s unfair losing.
What should come first?
What comes first is a balance between company, team, and the various possible focuses. New users? Existing users? Money? Or growth?
There can only be one top priority. But, that doesn’t mean that the team only works on one thing. Every team has to balance maintenance and feature work. But you need to carve out the space for your top priority to succeed. You usually can’t say no to everything other than number 1, but you need to say no enough that number 1 happens.
How do you communicate your priorities?
Priorities need to be communicated frequently, and with reasons and progress. You communicate priorities when you say no to things, and you communicate priorities in how you spend your time.
I like to use data to tell a story. If you can measure something, then you can use that measurement as an indicator of success. But since you manage what you measure, you need to be careful that you consider the experience holistically – looking at multiple metrics make it less likely that something will be gamed.
The current top priority of my team is a project we’ll call “Open Sesame”. We communicate why this is a priority using two main pieces of data:
User success rate with this action.
Support volume from users trying to achieve this action.
These two numbers show up every time we discuss it. They show up in our bi-monthly “what are we doing” post. They show up in our “what this project is” posts, and I bring them up every time we talk about this project.
Usertesting videos of users struggling to complete this action round out the numbers, and help engineers empathize with the problem, and the people it affects.
Aligning your actions with priorities
I started managing a designer this year for the first time ever. And like, I have no idea how to manage a designer, so unsurprisingly I screwed up a bit at first. And the way that I screwed up was that I was periodically asking him to weigh in on certain things that I thought were small, as he tried to make progress on the highest priority project for the team.
It turns out, the things I thought were the design equivalent of code review were… a lot more work than I ever imagined. So as I paid attention I realized that the design things that seemed “small” were really much more involved that I had imagined. Also, eventually he told me that this was stressing him out. We aligned his work better and let things that aren’t our top priority wait, for now.
One thing that can be a challenge for mobile teams in particular, is that right now Android is the largest and the growth platform.
Depending on what you’re building and your market, Android might not be your biggest platform, but it’s definitely an important one. However tech company leadership is often dominated by iOS users. If you talk about how Android is important, but only file iOS bugs, people will get the message that iOS is more important, whatever it is that you say.
