Building an effective product development team across countries
So — I have a question for you.
One of the teams I currently manage consists of 4 backend developers, 1 frontend developer and 1 QA engineer alongside 1 designer and 1 product manager. Each of these is a person with ideas, motivations, ambitions and personality quirks. They have different goals, different styles of communication, different backgrounds, and different amounts of experience; they live across at least 4 different countries/timezones, and they each have different ideas of how things should be done. They have different code styles, tool knowledge and require different ways to interact with to get the best from them. All work in a newly created team, with no existing team culture or process, and none of them have known each other for more than the few months they’ve been working together.
How do you build a highly motivated, effective team that works as a well-oiled machine to deliver features of high quality with a high velocity and speed as soon as possible?
In the following blog post, I’ll try to set out what our end goal is, how we intend to get there, and where we are in the process. Oh yes — it’s going to be a real rollercoaster of excitement, and I shall be surprised if Hollywood doesn’t reach out for the movie rights soon!
God, I hope our new joiners had a less confusing welcome…!
The end goal
When trying to achieve anything, it’s usually a good idea to start with a clear of idea what you want to achieve. (Is this the least informative sentence ever? I think it might be. Also, note to self: perfect tag-line for the movie!)
Or, to put it perhaps a bit more accurately, saying “We want an effective team!” is not concrete enough. Effective is a conclusion, not a set of behaviors we can observe and measure. In this section, I will try to explain what kind of behaviors we wish from a team, before discussing how to encourage such behaviors in the following section.
Side note: I am, from my time with the Manager Tools training, focused on behaviors rather than how people feel.
This is not to downplay the importance of how anyone feels; rather, it is from the principle that behaviors are measurable and concrete, whereas “Are you feeling motivated?” is somewhat more nebulous and open to interpretation.
If you sit in the corner, waiting for me to give you a specific task, my immediate question should not be “Are you motivated?”, it should be “Why are you not acting proactively to find a valuable task?”, since you might very well be extremely motivated, but just unsure what to do.
Your motivation or lack thereof is just my interpretation of the indisputable fact that you didn’t act in a certain way, and while I want you to be motivated, my immediate question should be on your actions not your mental state. Then we can talk about motivation later, and how to achieve that!
End of side note
So — what are the kinds of behavior do we wish to see? Before you sneak a peek at my list, try writing them down yourself. I’d be curious to see how yours compared to mine! Remember, they have to be behaviors, and specific enough to be meaningful.
My list comes down the following:
Proactivity and taking responsibility
We want you to act, without needing continued guidance, and we want you to understand the boundaries within which you are skilled enough to do so. We also want you to think about consequences and see the bigger picture: Do you see the current actions biting us in the behind in 3 weeks or 3 months? Say so!
Precise and efficient communication
We want you to be able to communicate effectively with your listener. You give them enough information to, in their context, understand what you are talking about, and what you are asking or suggesting. You seek to understand and communicate to the listeners’ context, effectively and efficiently.
Quality-focused execution
You understand that building a product that has direct consumers using it, means quality and stability is non-negotiable. You therefore write test cases for your code, you think about the context it runs it, you consider exception scenarios, and you test your code well before a pull request is ever made.
Seeking product and user knowledge
Building software requires hundreds of smaller decisions during the day. You seek to understand the product we build and the users of it, to take those small decisions as best you can. Database or enum? One-shot design or part of a greater whole? Important to test or not? Only by ensuring you, as a team member, have a good understanding of what the product is and who its users are, will you be able to make the right decision as frequently as possible.
Seeking task context
If unsure, you ask enough questions to ensure the task in front of you makes sense. You strive to ensure that you not only understand what to code, but also why to code it. You are able to ask not just how to do something but why, and if it’s even the right thing to do.
Honesty and openness
You admit your mistakes and take constructive feedback on how to avoid making the same mistake again.
Following process
You follow the process as laid out — and give feedback on the parts that do not work well.
It is important to remember that no one is perfect, and no one will display the above behaviors 100% of the time. We’re just squishy humans; we make mistakes. Secondly, it’s also important to note that some cultures and companies do not place as high of a premium on the independence of their developer as we do, and thus, everyone will show up with a different level of experience in implementing behaviors like the ones above. It is our job as a team and as managers both to select for the ones that might do well in such an environment and to help ensure the environment actively supports new joiners in these behaviors.
With all that said, the question of course then becomes: How do we encourage and enable such behaviors?
Encouraging behaviors
Ensuring these behaviors is easy, right? You just give the above list to people and ask them to be proactive, seek to understand the product, etc.! Job done, I can go home or have another cup of coffee, and prepare notes for whoever shall play me in the Hollywood adaptation! Excellent!
Though be careful what behavior to encourage…!
Except, no — it’s usually not that easy as just handing out a list. Behavior is difficult to build or change, absent fundamental pillars being in place to support them:
Fundamental skills must be in order
No one knows how to do everything, everyone is constantly learning, but there is a base level of skill necessary to be able to focus on higher-level abstractions than just “perform the task in front of me as I have been told to do them.” Luckily, I believe we’ve certainly hired good enough people that this is not a concern!
A supportive environment
It’s not enough for me to SAY you have to be proactive. We have to actively encourage and support doing so. When we see someone adhering to the behaviors we want, we must recognize it and encourage it, and when we see people not doing so, we must strive to understand why and help them adhere to the behaviors in the future.
We also have to demonstrate it ourselves. More senior members of the team must exhibit these behaviors frequently and clearly for others to see and emulate.
Reminders
No one remembers everything the first time around, and we must from time to time remind them of processes and desired behaviors.
Specific areas of responsibility
Especially when building a new team and culture where we are as a team focused as we are in Denmark, it’s easy to give everyone the responsibility for some things, and thus no one actually feels compelled to do so. Having someone be responsible for specific important things can help in building this knowledge and the practice in the team.
In the last few months, we have done the following:
- Upskilled new hires on technology and process
- Instituted all hands calls to build team culture
- Reminded people multiple times to remember to update their task status as appropriate
- Reminded people multiple times to log their hours
- Passed on the weekly build responsibility explicitly to one member of the team
- Continually given positive feedback on the good things, and negative feedback on the bad
While building a culture where such behaviors are automatic, we have to be constantly vigilant and constantly engaging with our team to continually give small but important course corrections. It takes time and energy, but it is well worth it to build a team that performs to a very high level.
Where are we now?
Nowhere near perfect, but trying!
I honestly don’t really have a good reason for adding this one, other than I like it! Also, whatever happened to David Hasselhoff…?
We try to instill these principles in what we do, what we say, and where we spend our time and energy. In the last week or so, I have personally had conversations with part of the team on:
- Precise and efficient communication
- Following process
- Quality-focused execution
And we strive to make these desired actions both explicit through these conversations and implicit through our actions as leaders and senior members of the team.
It’s going to an interesting ride — and I look forward to finding out who’ll play me in the Hollywood adaptation. I’m thinking Brad Pitt, maybe…?
