Building a strong development team
How to become a real software team and overcome obstacles like a bulldozer
They say a team is “only as strong as its weakest member.” They go out to hire unicorns, ninjas, gurus, hoping that their team will be one of the strongest in the industry. When they can’t find any supernatural beings, they say there’s a shortage of talent. Anyone that believes this crap doesn’t know what a team really is. I didn’t know either, until a few days ago. And now I do. If you have a group that functions as a real team, it’s much stronger than its weakest member. In fact, relative strength of its members ceases to matter once there is a team.
I’ve lead a team before. It was a geographically distributed team of four. I’ve only ever met one of the teammates in person, and only after having worked with them for a while. It was also a great team. We still keep in touch over our private Slack channel we’ve set up after the team dispersed following a financial crisis at the company.
I never thought I did a fantastic job as a lead. The guys would tell me I’d been the best boss they’ve worked with, but I knew I’ve made a bunch of mistakes. I don’t think I could’ve done things any better given the experience and circumstances. At the same time, I was convinced that I could do much better in future given the experience I’ve gained with that team, and the right circumstances.
Between then and now, I worked in one completely non-functioning team, and left it. I switched jobs and ended up working solo for a few months. About a couple of months ago, I got an opportunity to lead again. Our company hired two juniors and a senior developer to work on the front end team.
At a whirlwind pace, our new team transitioned from a bunch of individuals into a more tightly integrated group, and yesterday, I finally saw the moment when this group of people became a team. Most of it happened during the past week, and this my account of how it unfolded.
Concerns
We had our work cut out for us.
The technology stack I originally put together was quite non-standard, and complicated to explain. It was using some of the more exotic technologies, and a mix of object-oriented and functional code. There was plenty of technical debt resulting from the fact that we’ve soft-launched in short two months with just one developer — me — working on the front end.
I had trouble getting the junior staff up to speed. It wasn’t something I could do in a few short lectures, nor could they jump right into it — they would simply be overwhelmed by the sheer amount of stuff they’d need to learn. Even though I’d established the practice of juniors dedicating one day a week exclusively to learning, there was just too much ground to cover. It required time. And time, I felt, we did not have a whole lot of.
I started having doubts in sustainability of our current code base. Not because it was too bleeding edge. More like the opposite — it was too conservative. It lacked flexibility in many areas, and some things seemed very tedious. I first wrote an entire front end development framework. Secretly at first, then openly, I also worked on the next generation stack in my spare time.
I was convinced that better technology would solve all the issues. I was wrong, of course, but throwing tech at the problems was all I knew.
Lunch
Amid the chaos and my growing concern about team performance and the code, new desks finally arrived at our office. It was time to relocate the front end team to a common set of desks, next to each other. It so happened that I had things to take care of that required my presence at the office, so I decided to sit with the guys.
The new seating arrangement and the excitement that the novelty brought presented us with a great opportunity. It also coincided with team members’ very first paycheck. I proposed we go out for lunch at a nearby Chinese restaurant to celebrate.
We sat there, relaxing, talking about random stuff, enjoying the food. We took our time. After all, it was a happy occasion, and that did not go well with haste. It felt as if though the team was coming together for the first time.
On the way back, I was immersed in thoughts about why the atmosphere from the lunch wasn’t present at the office. We could eat and enjoy as a team, but why couldn’t we work as a team.
Pair programming
Later that week, it’d dawned on me. Pair programming! Why don’t we just share the code as we shared the table at lunch!
Pair programming had been on my to-do list for some time by that time, but I’d always had concerns about the potential impact on performance. That concern still seemed to hold, but team cohesion was more important at this point. I had a feeling pair programming would bring more good to our team than raw throughput, so I pitched the idea to the team. Their response was overwhelmingly positive. We decided that we’d talk about it more next Monday.
Something still didn’t feel quite right, though. “Team,” I thought, is singular. Pairs is still plural. There was still a missing piece to complete the image of a cohesive group working as one. Then I got another idea. Instead of doing pair programming, why can’t we just do team programming?
Mob programming
I jumped on YouTube and searched for “team programming.” The first hit was a video about something called “mob programming”, a presentation by Woody Zull on how his team discovered a way of working as a team. I immediately got a vision of our team working like that — one team, one keyboard, one screen. I was hyped, to put it mildly. I just knew this was it.
Because there was so much to explain, I simply decided to show the video to the team. That Monday, we gathered in the conference room as usual, and, without much ado, I started the video.
When the video finished, I expected a round of applause. Instead, I got a round of silence across the board. I glanced over the table, and seeing that nobody would step forward to offer their two cents, I broke the silence with a “Well? What do you think?”
The two junior programmers said they thought it was a great idea, but their tone was far from confident. I didn’t think they fully grasped the concept let alone its potential impact. The senior developer commented that he’d had experience with pair programming at his previous jobs, and that it did not always work, or something to that effect. I felt like he wanted to maintain his position as an observer — “Let’s see how it goes,” he eventually said. Nobody was willing to commit.
Even though I was a bit disappointed at the lack of buy-in, I let the hype drive my calls. Nobody was against it, at least, so it was worth a shot.
Bumpy start
We carried the big screen TV from the conference room to our office and set things up. We quickly settled on a few ground rules:
- One driver that types on the keyboard
- Everyone else are navigators, guiding the driver
- We take turns at the keyboard, switching every 10 minutes
The first day was just for look-see. We picked the simplest task we could find, and focused more on the mechanics of mob programming, rather than the task itself.
We used the built-in Windows 10 timer app to track the time. It wasn’t an ideal experience, but it worked acceptably well after we got the hang of it.
As one would imagine, working with a group of people requires a great deal of real-time communication. If you think meetings were tough, you haven’t seen tough yet. At meetings, people take turns to talk, and you mostly yawn while others are talking.
Here we have real-time exchanges, everyone focused and (mostly) engaged in what’s going on, social anxiety, highly technical instructions, desynchronized terminology (it’s amazing to discover how much we lack a common language even though we work in the same field). None of us were used to this kind of environment, and it was mentally taxing.
I was glad we chose a simple task, rather than a complex feature. We did not have the mental capacity to handle complex programming challenges and the challenges of the new way of working together, both at the same time.
After mob programming for the day, we concluded that it was fun. I would say the honest opinion would have been more along the lines of “interesting”, or “different”. I could feel that the senior developer was still not fully sold on the idea. Juniors probably had a misconception about their role, too. I tried my best to keep the train moving, and we agreed that we’d try it for a few more days.
Uncertainty
The second day was a bit smoother in the technical sense. We knew how this worked mechanically, but we were still unable to operate as a team.
At one point, for example, the teamwork was derailed completely. We got stuck on some tests broken by our last change. We discussed the possible solution. I came up with an idea, and, ignoring the senior team member, I proceeded to navigate the junior member at the keyboard. The senior colleague also ignored the rest of the team and started coding his solution at his own laptop. The rest of us completed our solution. It worked so we adopted it. We were about to commit the changes when the senior teammate commented, “Hey, my solution to mock C3 worked.” I told him that we’d already solved the problem. He was confused, and probably a little bit angry as well. It turned out we both came up with the same solution, and we both failed to see that.
I felt like this whole thing was starting to break apart, but we continued anyway.
Later that day, I got a bit of a push-back from the senior. “This is all fine, but can’t we work by ourselves at least some of the time?” He was not being rude or condescending in the least, but I did note the lack of commitment. Caught off-guard, I halfheartedly replied, “Yeah, sure. If anyone here thinks this is not the right way to do things, feel free to pick a task and go back to solo.” Deep inside, I knew that that would pretty much signal the end of mob programming.
I went to bed part frustrated part anxious. The original hype had toned down by that time. I was also tired due to the cognitive fatigue. Most engineers would probably agree that working with people is difficult, and I was clearly outside my comfort zone as far as that goes. The conflict between this difficulty and my conviction in the idea of team cohesion created additional stress.
Morning coffee
Next morning, I walked to the office as usual. It’s a 30-to-40-minute walk, but that day it felt a lot longer. Dragging my feet closer to our office, it dawned on me — I never took the time to explain why we were doing it!
I knew all too well that decisions made without the why are doomed to failure, or at least bound to miss the goal by a large margin. Yet, I’ve made the crucial mistake of not starting with why.
Once at the office, I waited for everyone to gather, and then told the guys, “Let’s go out for some coffee. We need to talk about how we want to proceed.” Some of them were already seated at their desks. One of the teammates gave me a puzzled look and said “Well… I’m always up for a cup of coffee,” and quickly added, “if we can afford it.” “Sure,” I said reassuringly, “of course we can afford it.”
The bakery down the street had good coffee. We quickly seated ourselves in the most comfortable part of the shop —the sofa corner. Sofas were comfortable, and it gave the meeting a domestic atmosphere, allowing everyone to lower their guard.
Unable to restrain my desire to jump straight to the point, I got us started as soon as our beverages were served. “Guys, I neglected to discuss the most important thing. I failed to mention why we are doing this, and I believe you probably don’t see mob programming from the same perspective I do.” Then I explained that mob programming was not meant to be a vehicle for training the junior staff, nor was it chosen as a method of increasing productivity.
The main point was the quality of the deliverables we produce as a team. “We have four people, two seniors and two juniors. If we give each person one task, two tasks are going to be done well, and two tasks are going to be done rather poorly. We would then be stuck with two patches we need to revise before they are production ready. ” Everyone nodded. Nobody could argue with that.
It was also about growing as individuals. We’d have to overcome our fears. The senior teammates would have to learn how to resist the urge to take the keyboard away from whomever was at it, and take more time to explain our ideas. When the time is up, we would need to be comfortable handing the keyboard off to the next person. Junior staff would have to learn how to deal with the fear of looking stupid in front of the peers. We’d need to learn to trust and respect each other. Productivity would come naturally as a result of this trust — being relaxed and having more fun working together is a condition for productivity.
Once I was done explaining, I added, “I don’t expect you to give me your answer here and now. Think about it until the end of the week and let me know your thoughts. If you have any questions or concerns right now, though, let’s hear them.”
The senior developer had only one question: “If we disagree about some solution, what do we do?” I sensed that they were probably referring to the glitch we had the previous day. I said “We simply pick the first solution that everyone understands well enough, and seems like it would work.” We all agreed that this was an acceptable solution. It didn’t need to be perfect as long as we could all agree. I quickly added just in case, “Besides, last time, we did not even disagree about anything. We both came up with the exact same idea. We just failed to coordinate.”
We spent the rest of the coffee break talking about what gear and furniture we’d like to have, to support our new way or working. We also talked about how we would solve for team members working from home. The tension that existed the previous day seemed like it was quickly melting away.
Shifting gears
The proper explanation of why we were mob programming had a very positive effect on the team. I could feel we were more aligned now, and that gears were now meshing together more tightly. It was also less tense and much more fun than the previous days. As I precaution, I ended our sessions an hour and a half before the end of the day so we could remain fresh throughout the week.
It all culminated on Friday, the last day of our first experimental week. We were solving our most challenging problem since we’ve started mob programming. We had to learn some new APIs, and work in one of the messiest and more complex parts of the code base.
Some solutions were proposed. Although I was pretty confident I could come up with an even better idea, I kept it to myself. First of all, there was no guarantee my idea would actually work. I just thought it would be better, but that was just my ego talking. Secondly, the proposed idea was good enough and we all sort of got it, so why not just go with it?
We started coding the first idea that was proposed, and worked our way through it line by line. We also drew diagrams on the whiteboard to clarify some of the trickier parts, and we exchanged ideas left and right until we came up with a better solution. Together. This solution was different from both our original solutions, and a lot simpler and easier to implement.
For the very first time, we came up with a solution in a wild idea cross-fire, in a way that we could no longer tell who came up with it. We were starting to become a brain cluster — a team. I rather enjoyed losing myself in this, and the fact that we were increasingly putting our egos aside. I felt that we could rely on each other and express our thoughts more freely because we knew others would correct us if we went off the track.
As we took a short break, we all agreed that this was indeed the best way to work. Not just agreed — we knew that this was the thing. Nothing we’d done before sounded like a good way to work anymore.
The goal
The icing on the cake is the goal we’ve set for us.
Thus far, we’ve only monitored performance without setting any particular goal. With the new way of working, it simply made sense to set a concrete goal.
When we work with people we can count on — when we work as a unit — we just know we can reach the goal. It may come off sounding shallow, but it’s a feeling you cannot experience until you’ve worked in a real team. With such a mindset, performance goal becomes a beacon, rather than a pressure point.
We went from no deliverables in the previous two weeks to two small but still meaningful deliveries this week, and a few tasks that were almost done. The two completed tasks were the same tasks juniors had been assigned a while ago, and they would probably have taken them a few weeks to complete given no assistance from the seniors. As a team, we completed them in a few short hours. For me this was the result I’ve been looking for.
We’re still a far cry from one delivery a day I’ve set for ourselves, but I’m also very confident that we’ll get there soon enough.
Tech does not matter
Yes the code base is still a bit messy. There’s still technical debt, and the architecture leaves a lot to be desired.
Since we’ve started doing mob programming, the stuff about the code that annoyed the hell out of me ceased to matter. The focus shifted from how to get work done better, faster, more elegantly, to how to get work done together.
I used to complain about our architecture being too punishing to mistakes. As it turned out, this was a non-issue when our combined brainpower plowed through any and all obstacles.
Challenges that seemed hard in the past suddenly looked easy and we were less afraid of taking them on. It felt like switching from a passenger car to a bulldozer or a tank. You suddenly realize you don’t need a paved road to go anywhere.
It’s hard, but worth it
There may be unexpected challenges. A teammate may end up needing glasses to see the big screen TV placed a couple of meters away. Or the furniture that was originally purchased may not be well-suited to a mob programming set-up. Home offices may need to be integrated, which may sound easier than it really is.
There’s also a question of compatibility, and the leadership skills get tested to extremes. If you are working with people that have never done this before, it may be too much of a shock to them.
Making this happen requires a great amount of effort, and even more commitment. It’s not easy. But it’s worth it.
We no longer have to do code review, because it’s done on the spot, as we work. The navigators can think a lot more clearly because they don’t need to worry about the mechanics of entering code into the editor. Juniors get exposed to the seniors’ thought process immediately because in order to navigate, we have to think outloud.
It’s great fun. That alone is a good enough reason to do this. What good is performance if you are not having fun?
If you’ve ever heard of the phrase “a team is only as strong as its weakest member”, this is the solution to that problem. Despite having two beginners in the team, the code our team’s produced during the past week is better than the code any of us could have written individually.
The final outcome is a team that can think and act like a sum of its members.
