The Moneyball Takeaways

I recently watched the Moneyball movie - a biopic after Billy Beane, the manager of the Oakland Athletics baseball team. It’s hard to imagine anything less relevant to me than baseball, but the movie is in large not about the game itself, but rather about how it’s managed and changed, so it did hit the right strings. 

The plot revolves around a baseball team manager trying to change the rules and build a team that would win under severe budget constraints - totally about management and, particularly, change management. Below are the key thoughts that got running through my head by the time the end titles made it to the screen.

1. If you gonna change the rules, there would be people who will oppose you. No exceptions. 
2. If you gonna change all the rules, almost everyone will oppose.
3. There still will be people who support you - keep them, teach them, trust them and respect them.
4. Building a winning team is not about picking the top players - it’s rather about picking the right ones, who cover the needs of the team.
5. The needs of the team is what it has to do to win - preferably, expressed in figures. Nothing else matters.
6. Winning is all about performance, performance is all about measurement - neither is about whom you like and whom you don’t.
7. While building a team you will certainly have to hire people, but likewise you will have to fire someone.
8. By the time the game begins the manager’s job is done - they can only watch how it develops and make a note of any required adjustments.
9. The fact that you succeed at changing the world doesn’t mean that you win. 

Everyone on your team is important

Over the course of my career in software development I got used to the idea that the key thing we deal with everyday is complexity. It shows up on different stages of our jobs, but most interesting cases are of course tricky bugs. Sometimes the issues reported by our QAs and especially by end-users get so messy that it takes a full crew of professionals to fix them. I have faced one such example recently and in addition to providing valuable experience and the feeling of satisfaction in the end, it served as an evidence supporting that all the roles we have in our team are of great importance and play best when assembled into a team.

About a year ago we have fixed a couple minor issues in our system. To be sure that we have that piece of functionality working properly despite any future changes we decided to create automated tests for it. Our QA engineers did get to this task, but because life is what happens when you have other plans, that happened only recently. Roughly at the same time another member of our team has found an issue in a distant part of the system, totally unrelated to that first bug, and fixed it using a certain code construct.

Once these two things met in our repository the new tests failed. It so happened that the developer who was digging into the failure wasn't in any way familiar with any of the two changes. The error conditions turned out to be tricky, so some folks joined investigation and it was eventually traced down to that seemingly unrelated last fix to be routed to the appropriate platform developer and fixed there. The importance of this event however took some more time to be recognized.

Another chapter of this story starts several months earlier. One of our customers filed an unpleasant data bug that we never managed to reproduce and understand. It was hanging there unresolved and made partners, so to say, unhappy. It's high severity kept it visible for us, but we still weren't able to do anything about the issue - till the moment when the events described in previous paragraphs took place. When I was doing a daily review of recent and priority items, I stumbled upon this nasty bug first and then spotted the one that caused all the mess outlined above. Something about them looked similar. The way the latter one was fixed suggested a new idea for repro steps for the former. Late at night this fresh approach was attempted and yielded positive result - we not only understood the reason behind the high-priority issue, but also knew that it is now fixed and could report that to everyone concerned - the problem was with the same code construct and the same platform issue that started the first bug.

This basically means that the data problem that we were so worried about took us a couple QA engineers, two developers, a product manager and a team-lead doing their usual jobs to track it down and fully understand - not to mention the significant amount of time spanned by all the activities that led us to this result. This might indicate problems with the product being developed or with the process, but the truth about software development is that such problems that eat enormous resources do happen and, if you are working on a large and sophisticated piece of code, you can only minimize them - not get rid of them completely. Complex issues also require different people to handle them - sometimes just to throw enough pairs of eyes and points of view at the problem. Even worse, there is an element of a slot machine to this requirement, because you can only partially design how and when someone of your team-mates will play his role in such a process - in most cases these revelations and discoveries happen merely because a number of people are doing their work properly.

Software development is sometimes messy work - especially when we speak of business applications. I would like to say that it doesn't have to be like that, but it seems that for most products getting complex enough to give birth to problems of this kind is just a matter of time. As a result we do need all of our people in their positions - QA engineers, developers, analysts and so one. This incident that we faced highlights the fact that even when I have no clue at all about the job that some people are doing at our office, it is still very valuable. The beauty of a development company and its processes is that one day any one of us - or rather an unexpected combination of our efforts - may save the company from something nasty or bring it to a new solid achievement. This simple idea is also a great motivator, because when I get tired with the routine and think that the work I am doing is useless, I can remember how almost the whole our team won the battle with that bug and see that one day me doing my job may save some thousands bucks for the company and countless hours of work to my colleagues.

The Candidate's Wishlist: Wrecked

After defending the diploma in the end of June I have finally got employed this week. I already feel how the job changes my life and get first benefits from it, but what is more interesting right now is the rapid mutation of my views on working as a programmer.

It is easy to track these changes because before engaging into a series of job interviews back in the last month I made up the so-called candidate’s wishlist – a set of about ten points, which I deemed important in the context of choosing a company to work for. What makes me speak of it here is the fact that some of the items are not fulfilled, though this makes me even happier with the new job.

One thing that I desired is a comfortable office. When composing my wishlist I tried to imagine the place where I would like to develop software: it had an A/C, a coffee maker and a teapot as well as other stuff of this kind – we have all of this. The workplaces with decent computers in my ideal office were distributed across several medium-sized rooms hosting three to five people each. That’s precisely where I failed: we have an open-space. I heard a lot of bad words about open-space and feared it a bit, but now I thank God for getting into this one. Although it makes the boundaries of my private zone elusive – almost non-existent – it is at the same time very friendly and welcoming. Being able to constantly see the colleagues around me working, engaging into passionate conversations regarding our progress and simply striding to and fro somehow motivates and, instead of distracting, helps to concentrate on doing my own job. After a couple of days there I truly believe that the way our office is organized plays a major role in making me a part of my new team – that’s something that, surprisingly, I have never heard about open-space.

On the other side, mere floor and walls – or their absence – can’t do much to improve and make easier one’s interaction with colleagues – that’s the people who make the difference. Upon coming to the office last Monday I found about three dozen interesting and kind men and women there, who are indeed willing to help me to get accustomed to the new job and environment. It turned out that not only my teamleader is concerned about my progress, but also other seniors do pay attention to what I do and, even though I am mostly learning new stuff now, they make me feel that I contribute a little to the progress of the whole company.

Beside the requirements to the office and the presence of experienced developers my wishlist included the desired size of the team – I thought that it should lie somewhere between five and eight people. The company failed this expectation as well – I am actually going to become the third guy working on a project and we don’t expect any more newcomers. At the same time, after the week on job I feel I can’t easily draw a line between our team and the others – we depend too strongly on those who do other pieces of work and they do depend on us to some extent. Due to this fact combined with the close to absolute availability of every colleague provided be the open-space I could say that the size of my team is about 30 developers, QAs and support engineers. This leads me to an interesting idea: the tradeoff between a small team and a large one is actually a tradeoff between the availability of many experienced colleagues to learn from and the ability to focus on a particular piece of work – software in my case – and the corresponding features and customers. It seems to me that the configuration with a very small team nested in a larger one and strongly connected with the latter’s other parts provides me both kinds of benefit. I know there are no silver bullets and free lunches and I might face some drawbacks in future, although I believe I am really lucky to have things laid out this way. Moreover, now I am not sure if organizing the development of the system of our kind is actually possible in some other fashion.

 

In addition to wrecking my wishlist this way, the job also affects my life outside the office significantly. I always stated that a full-time position is not only a source of income – it is a way to spend less as well. Now, as my spending halved, I have an actual proof of this hypothesis. Moreover, the positive outcomes of my employment are not limited just to the improved trade balance – I also smoke less and even procrastinate much less. On the other side, being obliged to work every day except weekends I can’t devote as much time to, say, this blog and my pet-projects as I used to. However, the lack of free time makes me manage it carefully to be able to do more. Combined with the fact that the job allows me to do something important for the company and its customers that’s a fair compensation. Finally, the ease with which I wake up these days confirms that I am pretty satisfied with my new employer and the regularities, which employment brought into my life.