Hi, my name is Eran Sakal. For the past few years, I've been leading the development of frontend projects from the planning phase until it's handed over to our customers. I'm writing this post at 4:00 a.m., which is the quietest time in the whole day.
At this hour, my kids are asleep, the phone notifications are on mute, the television is off, and an absolute silence surrounds me. During these magical minutes before I fall asleep, a stream of thoughts arises flooding my conscious, sometimes these thoughts prevent me from sleeping, forcing me to get up and write them down. This is one of those times, and I would like to share my insights on what makes a team tick.
Can you guess your teammate's thoughts?
Let's get something straight right from the start. The product I'm currently working on is blessed with professionalism across all departments. The team working on this product consists of a highly creative product manager, a super talented pixel-perfect designer, and some experienced developers that have seen quite a few things in their professional lives. Also, last but not the least, two QA people that are both perfectionists and realistic, so they catch (almost) everything yet know how to separate the wheat from the chaff.
Working with talented teammates lets you climb higher mountains faster and better. When each person does his best, assuming his best is being overall successful, everyone shines. In a healthy team, when you appreciate someone, you focus your energy on your responsibilities and let him take care of his/her responsibilities. It doesn't mean that you don't have strong opinions about how they should accomplish their responsibilities, but you count on them to do their best.
And still, unexpected things happen. In our case, although we function as a team, we still come from different departments, and each department has its agendas, and code of conduct. Communicating frequently about timelines, concerns, practices, and overall satisfaction can help to avoid confusion and mutual dissatisfaction. You don't need to agree with everything, but when you communicate things and also show respect to others, it's a win-win situation. Otherwise, if you are not paying attention, you might figure out later down the road that you all managed to climb high mountains, but different mountains separately.
So my first takeaway for this 4 a.m. musing is that, well, communication is vital. It can be handled in a structured way by enlisting a project manager, or in an informal way by “leading by example" and hoping that others will follow.
Foo-foo estimations should be taken seriously
I'm not sure "foo-foo estimations" is even a valid term. In my company, we use it when we want someone to provide ballpark estimation, which is guesstimation based on incomplete information. Those guesstimations help relevant stakeholders make decisions for the long-term. It is not something new; many companies use similar tools, and people use it also in their personal lives to be able to plan future events.
Being able to provide foo-foo estimations that prove themselves over time is a great skill. Some people can throw numbers immediately; I prefer spending a few hours setting some assumptions, reflecting on the resources, and trying to accumulate the effort and find references to those guesstimations.
It doesn't matter how much time you will spend to conclude the right number. Foo-foo estimations are based on personal experience, gut feeling, and assumptions that aren't necessarily spoken and cannot be treated differently. Always start with a ballpark estimation (you'll get better at it as you gain experience!), but follow with more methodical, detailed and quantified estimations as the project progresses. In any case, don't let the foo-foo estimations stick till the end.
Favor scrum over other software development methodologies
I know the title is problematic, and it needs clarification. TL;DR people love Scrum, and although there are several kinds of agile software development methodologies,Scrum is so popular that people sometimes treat Scrum and Agile as the same thing. After several attempts in the last few years to embrace other methodologies, I must admit that sometimes you must go with the flow and pick Scrum, not necessarily because it is the most suitable choice, but because it is a wiser choice, and let me explain:
Putting aside the traditional Waterfall process, you are probably familiar with the two agile processes, Scrum and Kanban. Each has its advantages and can solve different project management challenges. If you cannot choose between them, you can also pick Scrumban, which is a combination of Scrum and Kanban.
As I see it, when you do a product rewrite and need to include all the existing features (a.k.a feature parity) so your customers will be able to migrate to the new product, Kanban works best. Why? Because it provides superb planning flexibility, shortened time cycles, fewer bottlenecks, and continuous delivery. You can read more about feature parity in The difficulty of Feature Parity article.
But! Product rewrite with feature parity is not agile in terms of product as the customers must wait patiently until they see the fruits of your effort, and today it is trendy to ship fast and show progress to the customers (a.k.a most valuable product - MVP).
And this is my take, doing a product rewrite with feature parity is a lose-lose situation in the short-term. On one hand, you must put a lot of effort into rebuilding all the existing features in a way that will allow you to scale. And on the other hand, you are required to write a lot of code which takes time. People are rightfully impatient to this phase and want to complete it ASAP, so they will be able to start shipping new features to the customers. So based on the reasons above, in my next product, I will probably stick with whatever makes the other teammates happy because you are facing one hell of a ride, so the moral code and collaboration along the way are as important as the destination.
You must always show progress
Continuing my previous thought, you must always show progress because people strive to see progress; it is a psychological perception that took me a while to understand. My thinking is very logical when I'm standing in a crossroads, having a decision to make, I would usually pick the more challenging path if it has more potential of hitting the deadline. I have learned that most people will prefer a friendlier and more straightforward way, and honestly, I can relate to that lately.
As an engineer would put it - you can optimize for throughput or latency. Throughput is global optimization, which will save the company money in the long run. But people are people, time-to-market matters, and so is team morale and stakeholder management. Keep these in mind, and maybe the right way to go is to optimize for low latency. Get incremental features sets out the door early and often, even if it doesn't make sense from a pure resource-management point of view.
The subtle difference between owning responsibility and filling a gap
People would get new responsibilities over time. Regardless if they were given to them officially or de-facto, they are expected to adapt fast and show improvement. It might be frustrating at the beginning, but I believe that each should strengthen the adaptation muscle, knowing that shit might hit the fan at the beginning, and it must not bring you down as you grow while walking.
But sometimes you are not getting new responsibilities; you are just stepping into something you saw that is not being handled. It is your job to figure it out and raise a flag. My take is that I shouldn't assume people are aware of a gap, sometimes it is better instead to raise awareness about it.
One final thought, it takes a group to flash mob dance
I'm going to end this post with something that's been guiding me for years, an attitude that I try to embrace also in my personal life and to pass on to my children. People measure success differently, so talking about things does matter. Communicate with your colleagues, listen to what they say, ask questions to understand their point of view, and their pain points better. Be open to what they say, don't try to explain your side or reason with things unless they are willing to hear it, or they will shut down. Everyone sees things differently, so don't take things personally. Embrace the parts that you relate to and make adjustments. If you don't agree about something, it is okay; you should still be kind and respectful to their opinion; just be aware of the disagreement. If the other person is talking bluntly, don't react immediately, pause, calm down, and find the proper way and time to respond, it is never too late, and your reaction will be better that way.
Thank you very much for reading :)
Cover photo by Natalie Pedigo on Unsplash
Oldest comments (0)