Team principles to build great products
The way of working within a team is critical to building quality software that users love. The 3 key areas are People, Principles and Process.
Today I’ll focus on principles.
- Are you ok?
- Prototypes drive requirements
- We are experience led
- Early feedback, often
- One thing at a time
- Decision making is within the team
- Don’t be a dick
- ABC — Always be capturing
- Context is critical
- It’s ok to have a day off
- It’s ok to have an off day
- Keep your space organised
- It’s ok to ask if the meeting is necessary
- We don’t defend, we say “tell me more”
Are you ok?
We’re all on the same team, work is just one component of each person’s life. You have absolutely no idea what your colleagues are going through or have gone through. Make connections with your team, create an environment where people can be their whole selves.
Prototypes drive requirements
Creating a solution off the back of a list of requirements and asking users to ‘approve’ this before they commence building is equivalent to speaking different languages. A prototype can take 5 minutes, it can be hand drawn on the back of the napkin. I know what you see, you know what I think. A list of 1000 jira user stories is impossible for a user to conceptualise how the product will work. It may tell you what it’ll do, but it won’t tell you how you’ll use it.
Prototypes also help find missing requirements, force simplicity and empower users to truly influence a solution.
We are experience led
User experience is an integrated approach to our build. How the user will feel when they use our product is our product. It’s not separate, the experience is the product. It’s ok to say “yes the user stories are all completed, but this isn’t ready to put in front of a user”. This is not the domain of interaction designers and UI people… it’s all of us. It’s the Business Analyst asking “should we really ask all our users that question when it seems like only 1% of people use it”. It’s the developer taking pride in getting 3 screens down to 1.
We can formalise this through activities such as think-aloud testing with end users as part of our sprint. It’s creating empathy for those who we are creating for.
Early feedback, often
The relationship between a development team and everyone else should be an open door policy. “Hey I just wanted to run something by you”, “Can you drop in sometime this week and have a look at our ideas for the new feature”, “Do you think there are any risks with this new approach?”.
Create a culture where nothing is fixed, nothing is certain, everything is putty. Don’t wait for sprint reviews, walkthroughs or workshops to engage with people. Invite and encourage regular feedback, and listen curiously.
Change your relationship with feedback. It’s ok, it’s important. Just listen and ask another 100 questions. Avoid surprises. Formal events should be just that, a formality.
One thing at a time
Your team should focus on one thing at a time, and focus on it deeply. Don’t try reinvent the replenishment process including all adjustments, terminations for simple and complex products. First start on a new replacement order for a simple process. That’s it. Nothing more. When you get asked how you’re going to handle adjustments, say “I don’t know, we’re not there yet”.
Decision making is within the team
The team mix should be in a way that you’re not waiting for outside areas for information. Those selected to be in the team, particularly those from the business, should have the experience to make decisions and provide input. It is at their discretion that they reach out for items they are uncertain of.
The team mix is critical. A mix of technical and business/user resources that work together. If you’re a consultant, it’s a mix of consultancy, client, technical and users. When you’re developing your team structure it’s one bubble with all these parties, not separate bubbles for vendor and client.
This allows us to move very very fast, and as long as we’re getting early feedback, often, there won’t be surprises.
Don’t be a dick
Don’t gossip and have back room conversations about your team. Be direct and compassionate with all your parties. Work on your communication and connections with people to figure out how we gel together. Be nice. People are trying their best.
Treat people with respect. If someone is not performing as expected, be direct but compassionate, ask how you can help, ask if there’s anything we can do to help.
ABC — Always be capturing
Through the development process you’ll get 1000 “but sometimes we do x….”. “I think we do that sometimes…”. These off handed remarks that cause uncertainty. Have a mechanism to capture, then categorise all of this. I use post it notes and just have a catch all for all of this, then we jointly rank which issues we should be tackling first.
Context is critical
Context is a powerful tool that provides meaning to work and creates ownership. Who are you building for, what are they trying to achieve, why are we doing this. If you’re just seeing a list of requirements but you’ve never observed or interviewed some end users, you do not have the information you need to make autonomous decisions. You can’t say “I think they’ll also need x,y,z” because you simply don’t know.
Context builds connection. Deep connection with the people, purpose and process of a project empowers autonomy, decision making and initiative. Foster context. Record videos of interviews with end users, carefully explain why we are doing something.
It’s ok to have a day off
You need rest, you need a balanced life. Take some time off. Do the right thing and make sure your colleagues are empowered and have all the information they need to do your role.
It’s ok to have an off day
There are going to be days where you are burnt out, or simply not yourself. It’s ok.
Keep your space organised
You’ll use several spaces. A physical co-located design room, a confluence site, a wiki, sharepoint, MS Teams. Keep this organised. The cost of a disorganised space is underestimated. Think of the mental energy trying to find the latest version of something, the mistakes of starting on something that’s already completed, the stress that the confusion of chaos can create.
It’s ok to ask if the meeting is necessary
If you think a meeting can be done with a 1 on 1 conversation, or a 1 sentence email, say it. “Hey guys, I’ll chat to x,y,z and confirm. Do we still need this meeting”
We don’t defend, we say “tell me more”
When you’re presenting anything, welcome feedback, even if you think it’s ‘wrong’ feedback. Frame the conversation as welcoming early feedback, make it an open environment. A simple rule is that you’re not allowed to defend, you can just say “tell me more” or “thank you”. This only works if you start this process early. If your sponsors or users are seeing the solution for the first time after it’s been built… expect pain.