If anyone ever bothered reading the previous blog, this might sound familiar: I’m sitting in a train, on my way to Paris.

Before I go any further, I’d like to take a moment to clarify something:

This is a personal blog, if we happen to work in the same company, and you are not reading this for personal reasons: get lost.

The past few weeks have been difficult at best. Getting a team to work together can be a daunting task to begin with, but doing so when the product is poorly defined, customers are starting to flood the gates, and the company is undergoing a massive transformation (team-based organisation to business-units) is even more daunting.

Even more so, getting a team to work well together, in those conditions, becomes nightmarish.

Phase zero: Products, designs and customers

I love products. I love my products. I love making things better, fixing things, upgrading things. I love surprising people, in a good way. I love when things just work. I love when products work well, for a large array of people.

At my company, we don’t have just one type of customer. This is true for most software companies in the world, but because we’re special, even more so in our company. Our closest colleagues, but also our first customers are the operations guys. The guys who make everything work together. They ensure the servers run, that the pipes are clean and have enough capacity, they’re the ones who get woken up when something goes wrong.

After a few months in the company, I was the one who would get woken up in the middle of the night, when the operations guys ran out of options. I don’t blame them, and never will; they were just doing as they were told. But, having been on that end of phone call, I do understand how crap it is. How life-destroying and mind-numbing it is to get that SMS or phone call, and before you even have the time to rub the sleep out of your eyes, you know you’re in for a few hours. Your personal life will suffer from it.

I want to help them. I can help them. I can, with my little fingers on my little keyboard, help the operations guys get full nights of sleep. I can, with my meaningless abilities, improve their social lives.

The same way I love my products, I also love products that are well made. I love trying to find the simplest, most elegant solution I can come up with. I love the fact that a solution works for all the twisted combinations of use-cases that we can throw at it. I love when a design is responsive, not in the way it is understood by web designers, but when the way your software is designed means it can evolve drastically without requiring you to rewrite or rethink massive parts of it.

I love being able to trust my designs, but even more so, I love being able to put them to the test.

Phase one: Management

I hate management. I don’t hate people who manage me (quite frankly, I envy their abilities), I hate managing people, with a passion. The main reason I hate managing so bad is that I utterly and completely suck at it. I don’t want to have to think how someone feels before asking them to do their job. If they came in today, I believe I’m allowed to expect nothing but their utter best. I know a lot of things have to be taken into account when you ask a group of people to work, and sometimes, live together. Life always gets in the way, there’s always things happening.

I know this, yet when my brain is firing on all cylinders, it doesn’t reason like that; it takes shortcuts, it saves time on the most inefficient part of the process: people. The same way I am capable of leaving my FOSS beliefs and ambitions out of my professional life, I expect others to be fully dedicated and motivated when they come in, and leave their personal life at the door.

I have tried to manage people and be a technical lead. I’ve been trying for the better part of three years now. The only way I’ve achieved that was by preventing myself from doing anything technical. It is only through completely starving my technical brain that my social brain can emerge, in a way.

Now, I’m not saying that even when I turn off my technical brain, I become a “good” manager by any stretch of the imagination. The cost, however, of having to turn off my technical brain, is massive. It hurts. There’s no way around it. I don’t know how it got this way, but boredom hurts. And management is boring.

Social engineering is fun. Hacking people is fun. Trying to motivate people is nothing fun. I guess that’s why I’m such a big fan of dual-track management. I would have a legitimate reason to only take care of the technical side of things.

My boss, Sébastien (note the different spelling), has hoped for the better part of the last three years that I’d develop an appetite for management. I don’t think I have. The ways in which he’s tried to get me to manage people, though has had me feeling like a goose getting ready for the next gavage session.

Phase two: The accusations

Over the years, I’ve been told I’m arrogant and cocky. And every one who’s told me that is absolutely right. Recently, I’ve been told that I don’t take full responsibility for my team’s failures (or successes for that matter). I’ve also been told that I have a need for validation that most probably comes from not growing up with a father (yeah, management in our company goes way deep).

I don’t really see how refusing to own up with my team’s milestones matches up with wanting validation, but sure.

I’ve been told that I spent too much time on the little things. That I shouldn’t care whether a developer uses proper naming conventions when naming his local variables. That I shouldn’t drill down on a developer because one of his classes is a monster class that should be split in six different classes, none of them bearing the original name. That I’m not allowed to question the design of other developers. That asking them why they’re using a deep-copy instead of a reference is not useful. That by doing that, I “kill their creativity.”

Recently, I’ve been told I was acting in bad faith. Now, on a personal level, I’ve been insulted and called names more often than I’d care to remember, and I’ve developed a pretty thick skin in that regard. I don’t much care whether people tell me to go f myself, or call me names. Most of the time, I just laugh it off. But on a professional level, I’ve never been this insulted, this hurt. I guess this whole blog post just comes down to this.

Phase three: Retort

Everyone’s heard “There is no I in team,” so yeah, I do say “we will work all weekend.” What others don’t hear is the rest of my thought “because X didn’t test his code before leaving on holiday, and sticking it to the rest of the team.” What others don’t see is that the only person who came in to the office more weekends that not to “own up” on the team’s engagements and make sure that we don’t bleed customers left and right is me. I’m not saying that no person in my team has ever done over hours, because working right next to these people over the past few weeks has been a humbling experience. The past few weeks have made me proud of my team, more than I could’ve ever imagined a few months ago.

So yeah, I do require validation, but trust that it has more to do with my needing to reassure myself on the validity of all the sacrifices I’ve made for this company, and less to do with how many adults roamed around the many houses I grew up in. Yeah, there, fuck it, I said it: sacrifices. I’ve worked my arse off, working ridiculous hours to try and reach the ridiculous deadlines that always got dropped on us.

So yeah, I will beat a developer who doesn’t give me his absolute best. I will take it personally when someone produces a huge pile of crap and tells me that’s “his best,” even when it is obvious that it’s not. I will make a big fuss about people using tabs or spaces in Python sources, because everyone is wasting time and rewriting the full git history with copious amounts of sed, and I will ask a developer to redo his merge request eight or ten times until it doesn’t include commits that have nothing to do with his merge request. I am that anal, and I am that passionate.

Final phase

I gave the company the tools to have a development team.

I introduced version control management, and gave developers a platform where they could share, exchange, and discuss their ideas. Heck, not only developers, everyone in the company could come and comment. Gitorious was chosen because it considers everyone equal; a developer’s opinion doesn’t count more than a CRM chick’s opinion or an operation guy’s opinion.

I introduced version management, describing the rules under which we would increment our version numbers. Previously to that, it was up to the developer’s discretion. If he felt it was big, he’d increment the second number, or maybe the third. With those rules, people knew what to expect from a release, just by having a look at the release number. Again, this was done so that everyone would be equal in terms of knowledge.

I introduced bug tracking. Giving developers a tool to refer to when they didn’t know what to work on. Introducing milestones, roadmaps, and creating a QA position to double check that bugs were actually fixed, and that features were actually implemented before marking them as done. It gave people a common platform to discuss the urgency of specific issues, or the details of a not-so-urgent issue, or so they could ask whether one feature was feasible or not. Again, this was an attempt to make everyone equals in terms of knowledge.

I failed. The only people who know where Gitorious is are developers, and only because at some point I put my foot down and made everyone use it. Nobody discusses anything on the bug tracking tool, as most of the company has been told to never log on to it again. People don’t understand our versioning schemes, and even the COO, acting head of engineering, can’t figure out whether we’re going to release a dot release or a major one.

I failed on many levels and I can accept that without too much hassle. But I will not accept being told I’m acting, or have acted, in bad faith.