8 years ago, for the first time in my professional life, I felt totally and utterly defeated. It was after two months in my new role as a Team Lead.
I still remember the day my boss called me to his office, to sit together with our CTO on a new project. Back then, I was working for a small software company, building small to medium-sized projects for different customers. I was a pretty solid engineer, with 6 years’ experience of building numerous systems, products, and tools. The conversation itself is now a blur, but I will never forget one of the sentences during that talk – “… and I want you to lead this project as a Team Lead with 3 other engineers.”
At the age of 22, it was the first time I was officially responsible for others. It was a terrifying feeling, but it also filled me with energy to show my capabilities. Unfortunately, that excitement did not last long.
Two months into the project, all I could think of was, “Damn, why does everyone wait for me to get their job done? I’ve got too much on my plate, and no one is helping out!”. We were late, and I was pissed off.
Looking back, I served more as a load balancer than a Team Lead. When someone finished his task, he came asking for another one without even looking at our pretty 500-task-backlog (if you haven’t read Joel Spolsky’s Software Inventory, do it. It’s ridiculously good). I was so busy coding 120% of the time, that I didn’t give it a real thought. I just picked the next task and gave it to him.
I hated that feeling of standing alone. This wasn’t how I thought it would be. We didn’t work as a team and I wasn’t really much of a Team Lead. I knew it was up to me to get my head out of the code and talk with my teammates.
I decided to spend the afternoon talking with my team, sitting with each one of them for a few hours, figuring out how they feel about our current progress. After having a few conversations, things started to become clearer. I made so many assumptions, no wonder everyone was so confused.
I had never shared the context I had for this project. I never explained my plan to de-risk some of the critical parts or what those risks were to begin with. I never shared my thoughts and expectations on working together as a team. I didn’t tell them how I wanted them to work with me. I thought my expectations were obvious. They were not.
The sad reality was that things that were obvious to me felt strange or even wrong to them. They were surprised, unprepared, and above all – disappointed to find out about it so late. They wanted to help out more, if only I would tell them how.
I spent the night writing down everything I’d captured in my head: How I expect to work with them in terms of ownership and mutual help. The context of the project and the risks as I see them. Critical milestones we need to keep. I wrote it all down.
Setting explicit expectations 101, based on my painful experience:
1. Always start with working habits
Before anything else, you should explicitly communicate how you want to work with your teammates. It should include both the way you work with each and every one of them, and also the way you expect them to help each other as a team.
- Work assignment
How do you want them to take a new feature (or task)? Do you expect them to take it from the backlog or should they talk with you before making that decision? Maybe you prefer different behavior from different people, depending on their experience level? Figure it out now, have some sort of plan in mind.
- Define what “Done” means to you
Can you clearly define what it means to complete a task or a feature? It may involve code review, tests coverage, or sitting with the product owner to validate the user experience. Don’t let implicit assumptions confuse your teammates. “Done” should be agreeable and crystal-clear to all.
Do you want everyone to own features they wrote? If so, what does it mean to own a feature? Does it include fixing bugs and knowledge sharing? Does it include helping out with production issues? Write down the specifics.
- Commitment and deadlines
I highly recommend “A Language of Commitment” by Roy Osherove. Share it with your team. Create a baseline you both agree on and will be measured by.
2. Make risks visible to everyone (BIG white board)
What scares you the most about this project? How can you de-risk some of it? What your teammates think of these risks?
Once I had these risks visible to everyone, we had a great discussion on how to de-risk or invalidate them. People were sharing their thoughts and we added a few more technical risks to the board based on our conversation.
Having a visible risk list, sprint board, backlog, or roadmap does not mean explicit expectations (this is a common beginner’s error I was guilty of). But it’s a great first step forward to create visibility which is crucial. That leads me to my next point.
3. Make your Technical Lead accountable for technical risks and technical growth
Explicitly assign technical risks to your technical leads. Ask them to spend a few hours and prepare a plan to handle these risks. It may be as part of working on other features, writing a proof-of-concept, or anything else that they believe is right. Be there for them to offer a few more solutions and provide feedback, but it’s their responsibility to come up with the plan.
Tell them that you expect them to take care of technical growth for the other teammates. It means looking out for technical debt, conducting code reviews, improving the team’s technical skills via lectures, sharing links to great articles and teaching as much as possible. You don’t want to hear “we have shitty codebase”, you want them to take action and have a plan for it. You don’t want to hear “I’m the only one capable of doing code reviews”; you want them to train others to do it too.
You’re building a team. That means everyone should have their own responsibilities, both to deliver results while also looking around and helping others. Your Technical Lead(s) can help you building that team, if you let them.
If you don’t have anyone in your team you can count on at this point, make it your goal to train someone for that role. You cannot be responsible for both personal and technical growth in the long run. You’ll be mediocre at best at both.
4. Refine your expectations and provide feedback on your 1:1
Take the time in your 1:1s with your teammates to talk more about your expectations from each other. Provide feedback by focusing on the behavior you would like to see. Ask for feedback on the way you’re leading the team. A few guiding questions that come to mind – what can I do to make you happier at work? What can I do to make you more productive? What are you missing? What do you enjoy most?
This transition will take time. Use your time together with your teammates to maximize your team’s overall performance, agility, and fun.
I found out that I enjoy building a strong team even more than writing code.
By “dumping” my expectations on paper, I was forced to imagine the working environment I really want to be a part of. My implicit expectations slowly became something tangible that I could talk about with my teammates. I spent hours with each one of my teammates, talking about what I wrote, and finally discussed what we both wanted and how we could get there. I created an alignment.
I felt that I was no longer alone in this journey, nor that my teammates had to guess what was bothering me. Having explicit expectations helped me to make a transition from a coder role, to a mentor role. It took time, but it was the first step in my long journey to become a better manager for my teammates.
About The Author
Oren is also an Engineer at Commerce Sciences (#2 employee), where he focuses on building the company’s data infrastructure. Prior to Commerce Sciences, Oren served as Director of Engineering at Delver (acquired by Sears), where he was responsible for the development process, delivering kick-ass products, and growing the next generation of Team Leads in his group.