My tech team is organized into squads - cross-functional teams owning end-to-end feature development. The squad leadership is a joint collaboration of a product owner, a project manager, and a tech lead. As the business expands, more squads are needed and it falls to me to fulfill these new tech lead vacancies. To facilitate professional growth, internal promotion is favored over external hires. Along the way, I learned a few lessons.
It starts with a job description
The one thing that makes or breaks the promotion is the job description. A vertical promotion from junior to senior involves performing harder and grander tasks with tighter deadlines, in other words, being more proficient a what you have already been doing. A promotion to a leadership position is more “horizontal” in that sense. Pretty much like the time you left high-school, I don’t think any amount of prior experience can truly prepare one for what comes next.
Our tech leads work with people across all principles to provide a cohesive technical vision for the squad, contribute to the product strategy, and coach their members. In that role, many activities are new to them. They will be working with people whose functions they haven’t fully comprehended, like a tech lead with FE background working with DevOps for a deployment plan. They are asked for estimations while given far less details than what they received pre-promotion. They are exposed to HR matters around the well-being of their crew, not all of which make everyone happy. And just sometimes they have the trauma of having their handcrafted solution taken out of context for an entirely different thing and 3 days to deliver. Given the drastic change in scope of work (and the PTSD), it is understandable that post-promotion, some feel like a fish out of water. Unfortunately if there is a structural approach to eliminate this sense of disorientation, I haven’t found it yet.
While it is tempting to propose a five-page long job description listing out all little details one is supposed to perform and hence solve the challenge once for all, the managerial wet dream is nothing more than a motivational debt. Software development rewards people for their creative prowess and that in turn attracts great problem solvers to the craft. Practically spelling out what one needs to do is the opposite of that. The job description should enable the person to picture the boundaries of her authority and the impact she has on the team without resorting to dictating the specific activities. Everyone will have different responses to “make tactical moves to ensure successful deliveries”, or “look after the career development of team members”, and that’s part of the growth. Take that, Tiger Mom!
Strength in diversity
In the previous year, the squad model had some initial successes. The first two squads jelled and performed well, relatively uneventfully. Structurally. both were the mirroring image of each other: BE-heavy, big data focus, led by old-timers. So when it came to the next new squad, there was a strong urge to copy the earlier success: same leadership profile, same structure, and same kind of work. That should be easy, the management knows what to do, the promoted people have existing role models to follow, and things probably fall into the right place like they had done before. That was as close to a squad printer as I could think of.
In reality, my third squad was FE-heavy, had a strong interest in UI/UX topics, and had a product owner stationed away from the main body of the team. It couldn’t be any more different from the former two. I am glad that this happened.
A parthenogenetic offspring of a squad would have been an easy choice down a slippery slope.
I didn’t realize at the time, but collectively the technical discussion had already leaned towards the server side of thing more than it should. It is normal that individually each of us turns our face towards what we know and against what we don’t. But it gets dangerous when we all turn towards the same thing, we get ignorant of our faults and prejudices. In OOP, that is known as closed for modification, and closed for extension too.
The identical leadership profile would also send the wrong kind of signal, that one has be X and work in Y to get promoted. Everyone with a different profile probably feels unappreciated like a 40-year-old on Snapchat and take their chance elsewhere.
With the birth of the third squad, I got to learn the importance of a design system, the vast untapped advancement of browser technologies, and the bias in BE-FE collaboration. All these are areas of improvement that wouldn’t have surfaced if we had gone down the easy path and promoted yet another BE engineer. It itches me to sound like a social justice warrior, but we did find new powers in diversity.
The support structure
No, the new squad was not released to the wild to fend for itself. That would have been bogus.
In fact, the support structure was the one area received the most attention back in the squad formation. We defined the 3-prong structure where product, technology, and agenda support each other. The right people were hand picked for the backbone and the remaining vacancies received the highest recruitment priority. Meeting plan was laid out so everyone had multiple outlets to discuss their opinions.
The support structure was least of my concern, till something hit me in the face, something technical yet also... sociological.
The new squad got its people and work split from the two existing ones, like a cell division. Hence found itself co-contributing a number of code repos with the others. That led to some confusions where its realm of existence started and ended. The team operated with a constant fear of stepping on someone else’s foot. The organizational structure was changed and had not been reflected in the software interface. Wham! It was such a classic case of the Conway’s law that I was awed to observe it first hand, yet hurt for not seeing it coming earlier. The law was one of my favorite engineering observations, right up there with Murphy’s.
The following rectification was relatively straightforward. We educated people about the boundaries of squads, brought in service contract to strengthen the interface between them, and proceeded to splitting shared services into smaller ones where it made sense.
A personalized journey
Accompanying the tech leads on their way through aforementioned obstacles was a rewarding experience but easy it was not. There are many questions yet few definite answers, how many tech debts are too many, when an internal tool should be made. Much variation in preference, some are more than happy to deal with abstraction where others are keen on a transparent view. And much uncertainty ahead for that no plan can account, how one accounts for spending a month waiting for an engineer to onboard just to have the guy quit a day before his start.
It is probably apparent now that I haven’t done enough of this to actually know what I am doing. But I am experienced enough in software development to deal with uncertainties. And I am invested in getting it work for my team.
The Agile Manifesto has it that
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
They are good guidelines to drive our weekly catch-ups. We keep a very experimental approach at what we are doing, and maintain a close feedback loop. What work are replicated elsewhere, what don’t are studied. But most importantly, I always try to be a thought partner through out this journey. Interactively growing a team where people are collaborative and open about their problems today is more important than having it down to a science with a rigid plan tomorrow.
If one day I have a toddler, I ain’t no need for books.
Onwards.
