The diary (aka bitácora): towards alignment in distributed environments

Introduction

There is a virtuous circle that many think is key for any organization to achieve success:

I want to focus on autonomy and its relation with alignment.

I do not know any single smart person that do not like autonomy. Definitely I want it and most of the managers and developers I have worked with too. There is no doubt that we achieve the best results for ourselves and the organization we are involved with with great doses of autonomy.

Autonomy though, as usual, requires high levels of coordination in order to be sustainable over time. It requires mechanisms of check and balance against a plan. Take a look at Scrum, for instance. It proposes to do checks and balances against the backlog every 2 to 6 weeks aprox., at the beginning/end of every sprint And it forces also to stablish a daily check and balance against the micro plan every day. That is a lot but it is the price to pay for getting autonomy.

And this is because the success of a group completely depends on the alignment of its members. Our tendency of "taking our own way" (entropy) is so high that organizations need people and many processes just to make sure everybody fight hard against it.

Definition and a little bit of history

I think it was 2004 when I started my relation with Fotón S.I. crew. Fotón is an open source company from Gran Canaria, founded in 1998, lead by Mike Vazquez and, back then, also by Gonzalo Aller.

Working with Fotón SI had a huge impact on the way I perceive management. It worked as a catalyst. I learned with them in a few months what takes ages for others.

Fotón was formed by a group of very talented and young hackers. The decision processes were very participative and transparent. Let me put you one single example: the basic accounting of the company was open to every employee, including salaries.

In their peak times they were around 20 people but it was strange to see more than 5/6 in the office. Most fotonians worked from home most of the time. They were based in Gran Canaria and my little company was in Tenerife. It was a distributed environment.

Going back to Foton, a key variable that balanced autonomy and alignment  in that distributed environment was THE DIARY, a simple concept but very effective.

Most people right now are probably thinking about that little notebook that needed a key to be opened where some boys or girls write their thoughts at early ages. Obviously that idea has little to do with what I am talking about. The term bitácora, a short way in Spanish to refer to the ship's log, is closer to what I am talking about.

A bitácora is a log chronologically organized, written by the ship's captain, kept in a wel define place where the most relevant events related with the ship, the crew and the journey where described. It had two main goals:

• Analysis.
• Report.

By writing on regular basis what happened in the ship, captains were creating a tool that allowed them to learn from past experiences. It was a very precious treasure, so preious that needed to be destroyed in case the ship got into the wrong hands. It was way more than the Black box of a plane. It captures the most important knowledge. If the captain got sick, for instance, or died in combat, his replacement used the bitácora to analyse the past history. Many of you are familiar with this concept since it is popular among scientists, archaeologists, etc.

The bitácora worked also as a reporting tool. After a few months sailing, it was impossible for any captain or officer to remember details about the trip if they were not written in real time. Providing a report about the trip was impossible without the bitácora. One interesting point was that, once written, no entry could be modified. If the captain made a mistake, he needed to create a new entry correcting the mistake, like in a check-book.

Fotón was a pret-a-porter development company organized per project. Each project had its own diary/bitácora. Following its culture, everybody had +xrw permissions in every bitácora. Agreed labels were used for different purposes: identify each user, assign relevance a specific entry through colours, etc. This idea was implemented in a hacked Twiki, integrated with Request Tracker and a mail service for notifications. A very smart, geeky, simple and efficient implementation for the time. Like all the wikies back then, UX was not the main feature but for console lovers.....that was no issue.

So Fotón extended the concept of the bitácora to a new level, going from an individual oriented tool to a group one, that is, they took a collaborative approach with a great result.

I still remember the day they explained and showed it to me. I was amazed, excited and cautious about its scalability. I was already used to write regularly what I was doing so the main hurdle did not applied to me: I had the habit. The collaborative approach was new to me though, together with the implementation.

How come something so simple has such a high impact? What makes reading what others do, think or feel so valuable? What is the relation of writing what you do and being efficient as a team? What a diary has to do with alignment? And here is the question that most people that face this tool/process for the first time ask: isn't it the diary a tool to control me?

Let me start with the last one. The bitácora is a tool to control yourself. If you think you do not need to regularly check and balance your actions against your plans, your colleagues expectations and your company goals is simply because you are not senior enough, period. The diary is just a way to achieve that, like the stand up meetings or the burn down chart.

You decide what kind of information you should include in the bitácora. Here is the main rule. Knowing that is open to those you work with, add what you think is :

• Relevant to you.
• Relevant to your peers.
• Relevant to those you interact with like, managers, other teams, customers, etc.

Do not add information that only one person should know about or that you would not say in a team meeting. Simply use your common sense. For instance, if I am frustrated about something.... I add it in the diary if I want to share it.

Fotón used to open the diary about a specific project to customers and third parties involved on it and it worked beautifully. Of course once in a while somebody wrote something inappropriate, but the benefits of these diaries were so high that assuming the damage was out of question. It became an outstanding engagement tool, as good as the best sprint planning meeting.

Very soon I experienced myself the benefits of getting the habit of writing regularly in those project diaries I was involved with, reading what others wrote and interacting with them through the diary. I got a sense of control of my day to day work and, even better, of what everybody else was doing. Control in a good way. Sync meetings were reduced, asking for weekly reports made no sense,... we were a more efficient, coordinated... better aligned organization, even in our distributed environment, despite working in several projects at the same time, with different customers, third party companies or different working schedule.

Conclusion

In many ways Fotón diaries laid upon two ideas that today are very popular: semantic and social (in a twitter way). I believe that the diary is a key complement to agile methodologies, specially in distributed environments.

In my next article I will describe in detail the concept and what the perfect implementation should look like, based on my experience since I have used it widely since then.

Series of articles

1. The diary (aka bitácora): towards alignment in distributed environment.
2. Bitacora: environment definition.
3. Bitacora: personas
4. Bitacora: Impact mapping

The following one will define the personas. This section will be updated with the coming articles.

Apply agile methodologies to upstream development environments.... if you can.

 Introduction

When the Agile Manifesto became popular and based on them, agile methodologies like Scrum, XP or Kanban, upstream development was in its early stages as collaboration ecosystems of companies.

Only a few for profit organizations embraced developing upstream back then. Most of them were small and heavily influenced by FLOSS engineers vision. Free software communities were basically driven on personal basis or the very lucky ones, together with "sponsored developers". In general, these ecosystem were not part of companies strategies.

Today, more and more companies are getting fully involved in community projects as stakeholders, not just consumers or simple contributors.

They frequently start as consumers, then, little by little they become "upstreamers", that is, they share/publish their code with the goal to have it merged (upstream code). Not without effort, many of them become successful contributors.  After some time, some of them end up understanding that is "cheaper" to play by the project rules. In summary, they learn to become good citizens.

A subgroup of the above companies end up including these collaboration ecosystems as part of their own strategies, going from contributors to  key stakeholders. A necessary step to achieve this goal is to work upstream.

Walking this path present many challenges. One of the toughest ones is related with the differences in development methodologies used internally (mostly agile) and those used in the collaboration ecosystems.

There are two fundamental variables that, in my opinion, determine this challenge:

1. Environment
2. Culture

Challenges

1.- Environment

There are two dependent variables that were not taken into account (or just partially) when the agile methodologies were defined, that are relevant in upstream development:

1. Community projects are global environments, that is, contributors are located in different "offices", frequently in different time zones.
2. Probably due to the original amateur condition of early contributors, together with the "distributed condition", the development processes (so the tools) in most mature community projects, consider, manage and tolerate high levels  of latency.  "Real time" is restricted to IRC discussions and events/conferences.

These two factors has made open source what it is today. They have been "success factors".

Agile methodologies do not embrace "distribution" environments. The widely accepted recommendation is that teams should share a physical space. It is way more than a recommendation. It is somehow a requirement.

The second case, "latency", is considered by agile methodologies as a waste. It is not tolerated.

2.- Culture

Free Software was born as a reaction to a system that promoted corporation interests over developers, so users. The agile movement was a reaction to those methodologies that put process first, not people. Hence, it is obvious that both movements share a lot: people first. 

This is reflected by some when saying that FLOSS development is agile.

In my opinion, there is a big difference between what agile methodologies and what Open Source development propose in terms of principles.

Agile methodologies promotes a strong team culture. Open Source was born "based on champions". FLOSS culture normally applies the meritocracy concept to individuals.  Open Source projects are organized around contributors, around specialists, not around teams, as we understand them in corporate environments.

This is no surprise since Agile was born in companies/corporations and Open Source was born as a viral movement, grown "by aggregation".

The conflict

In my opinion, the more the industry embrace open source, and as result, open collaboration, the higher the conflict developers and managers will face due to the above challenges.  Companies are becoming more distributed environments and are working more and more upstream, instead of simply being consumers or occasional contributors.

In consequence, it would not surprise me if we hear more and more about  "corporate development methodologies" (a.k.a. agile) vs. "upstream development methodologies" (a.k.a. FLOSS).

Scrum, XP, Kanban -ish fans will need to face those challenges and find solutions in order to succeed in open collaboration environments. In the same way, based on the increasing influence that companies are gaining in these ecosystems, FLOSS methodologies in a few years will differ from what we knew 10 years ago.

This conflict will not be (is) about a R&D vs a product/service vision, it is not about creativity vs efficiency, it is not about micromanagement vs autonomy or teams of juniors vs specialists either. It is about methodologies applied to specific environments and its limitations. Maybe a simple update of the most successful agile methodologies will do the job.... or maybe we need to revisit some of the principles.

If you got here, maybe you want to take an extra step and answer these questions. I would appreciate it:

1. Do you perceive this conflict as I do?
2. Am I missing other key elements in the diagnosis?
3. How do you think we can adapt agile methodologies so they can be adapted to FLOSS environments?
4. I am interested in knowing how you adapt agile methodologies to overcome the above challenges. I plan to write about my experience these coming days.

Where the corporate and the upstream worlds meet.... or collide.

From the corporate world I frequently hear how hard it is to predict and track what upstream developers do. On the other side, developers that work part or full time  upstream frequently underestimate the need for communicating what they do in a way that enable others (or themselves) to provide deadlines and effort estimations. Upstream and product "time lines" and cultures often differ too much to be compatible under the same environment.

Developers that come from the "product" side of the story often refer to agile methodologies like Scrum as a good approach to solve this collision. It is unclear though the applicability of this and similar methodologies to highly distributed environments, where latency is high. Although most accept today that FLOSS development is agile, I find hard to assume that we are close to find good answers when it comes to development methodologies and upstream.

There are several different scenarios I have worked on where I have to question everything I knew up until then about this particular topic. In a couple of occasions, with a bigger or smaller community, the people I directly worked with were upstream. This allowed us to define up to a great extend the methodology we worked with.

In Linaro now this is the case for a particular project. But in general, in my Group we work upstream (in the Linux Kernel), that is, we cannot define the methodology since it comes defined by the project itself. It is not the first time I face this situation although I never did at this scale.

When you are upstream, the methodology used by the core team, together with how the project work packages and workloads are organised heavily influences the success in getting contributions from third parties. Together with other key variables, how you manage latency determines how many people can follow you and potentially contribute. In summary, the faster you move the harder it becomes for contributors to collaborate with you.

Hence agile methodologies come with a high risk: isolation. And this is obvious by just analyzing the prerequisites associated with the methodology itself.

Obviously this does not mean that scrum and other methodologies are not great ones. I am just pointing challenges associated with apply them when working in a community that you drive. You need to balance the efficiency of your team with the contributions you might potentially loose from externals.

The challenge is even bigger when you are just a participant in a community. In some way, your team goes beyond your colleagues at work. Latency is frequently too high to even consider yourself and the people that works close to you "a team" in the classical sense of the word.

If your own team is distributed, even if they are in the same time zone, then we are talking about the real deal, the master challenge for managers and developers. 

Imagine now that your team is formed by 10 people distributed in 6 different time zones in 3 different continents. Then you take one of those cool books that tries to explain how to create great software using this or that methodology and, in order for you to finish it, the writer must be a really good one or you really need to be an avid reader :-) 

Still you need to make plans, to predict when a feature will be finished, when it will be merged, you still need to manage dependencies, expectations, budgets.... you still are tight to somebody else needs and requirements. You still need to fulfil expectations despite the fact your control over the environment is limited. You have team mates that depend on your work, that needs to know what you are doing and how.....  you are still part of a business no matter if you develop upstream or not.

How can you make compatible the upstream development processes used in the community you are contributing to with the way your company works? And how about your customers and partners, if you have direct relation with them? How can you take the good things that agile development propose and apply them to an environment with high latency, where one of your bigger challenges is to have an efficient team meeting, since people are distributed across the planet?

At Linaro, the engineering management team, together with our PMO, are taking a close look at this challenge, in order to iterate from our current system to a more efficient one, better adapted to our new reality, after our significant growth during the past 18 months. The idea is to find a place where corporate and community processes meet... without colliding. You cannot stop adapting, innovating, trying new things..... or you pay a high price.

One of the great things about Linaro is that we are a unique environment so we can innovate at various levels, not just at the technology one.

Open Sorce Forum at CebIT

For those of you attending to CebIT, let me tell you that I am giving a talk about what we do at Linaro on Monday March 16th at the Open Source Forum. It is the first time I talk about my current job in public so I am very excited about it. It will be also my first time in CebIT so double doses of excitement. And yes, I will talk a little bit about Linaro new initiative, 96boards.

Core Dump

The past months we have published a few articles about what we do at Core Development Group at Linaro. Our blog is called Core Dump. Check it out.

Team blog: more than just a blog.

Motivations

Creating high quality contents takes time. A lot of people write nowadays but very few are writers. In the software industry, most of those who write very well are in the marketing side not on the technical side.

The impact of high quality contents is very high over time. Engineers and other profiles related with technology tend to underestimate this fact. When approaching the creation of contents, their first reaction is to think about the effort that takes, not the impact. Marketers have exactly the opposite view. They tend to focus in the short term impact.

Successful organizations have something in common. They focus a lot of effort and energy in reporting efficiently across the entire organization, not just vertically but horizontally, not just internally but also externally. Knowing what others around you are doing, their goals, motivations and progress is as important as communicating results

One of the sentences that I do not stop repeating is that a good team gets further than a bunch of rock stars. I think that a collective approach to content creation provides better results in general, in the mid term, than individual ones. Specially if we consider that Free Software is mainstream nowadays. There are so many people doing incredible things out there, it is becoming so hard to get attention....

Technology is everywhere. Everybody is interested on it. We all understand that it has a significant impact in our lives and it will have even more in the future. That doesn't mean everybody understands it. For many of us, that work in the software industry, speaking an understandable language for wider audiences do not comes naturally or simply by practising. It requires learning/training.

Very often is not enough to create something outstanding once in a while to be widely recognized. The dark work counts as much as the one that shines. The hows and whys are relevant. Reputation is not in direct relation with popularity and short term successes. Being recognized for your work is an everyday task, a mid term achievement. The good thing about reputation is that once you achieve it,  the impact of your following actions multiplies.

We need to remember that code is meant to die, to disappear, to be replaced by better code, faster code, simpler code. A lot of the work we do ends nowhere. Both facts, that are not restricted to software, doesn't mean that creating that code or project was not worth it. Creating good content, helps increasing the life time of our work, specially if we do not restrict them to results.

All the above are some of the motivations that drives me to promote the creation of a team blog wherever I work. Sometimes I succeed and sometimes not, obviously.

What is a team blog for me? 

• It is a team effort. Each post should be led by a person, an author, but created by the team.
• It focuses on what the team/group do, not on what they will do, what they think or what they want. Why? because a team blog is way more than a promo tool, it is also a reporting one.
• It is supported by a communication expert as editor, not just to increase the quality and potential impact of every content, but to increase the team skills as writers in a practical way.
• It is management driven because it requires to embed it in the team processes and group dynamics. So it requires analysis, a clear goal, follow up and activation energy, specially during those moments in which the team workload is high, so writing is not perceived as a high priority. 
• In order to ease the identification of the team with the blog and vice-versa, the promo aspects should serve the team and not the other way around. This is a key difference between this action and other common marketing efforts done by every organization.
• Selecting the right topics to write about is not a question since, as mentioned before, the team blog is about what the team is working on. The question is about when to publish, together with the approach used to create the articles. Again, a management point of view is essential here. That view can come from different areas of the organization or within the team, but has to be there to take full advantage of the effort.
• It feeds engineering reports. It saves time on this task in the long run.
• If the goal of the action and the vision brought up by the editor are set up correctly, the team blog should also feed the technical marketing and customer engagement efforts of the organization/business unit. 
• In the mid term, the blog serves as input for evaluating the performance/accomplishments of the team as a group, when associated with the key objectives previously defined. This is true not just from a management or customers perspective. What is more important, the team blog serves as evaluation input for the team itself too. The retrospective that this action can provide is essential for the growth of any team. 

Core Dump

I am pushing such action once more, this time at Linaro. The name of the blog is Core Dump. My presentation describes the motivations and goals that drives it. There is a talented group of professionals behind it so I hope that in just a few months we will be able to evaluate the results. I am confident we will succeed since we have every required ingredient.

First weeks al Linaro and other things

I few weeks ago I announced I was joining Linaro. I work there as Director of Core Development Group. I moved from Prague to Cambridge (the original), that is, from continental to oceanic climate. From dry, cold in winter and hot in summer to wet, soft in summer and above zero most of the winter. In theory an improvement, you might think. Well, depending on much it rains. I will tell you better in spring.

A few days ago The Mukt published and interview where I explained a little what is Linaro and what do I do as Core Development Director. 

Core Development Group

I can add that Linaro is an engineering focused organization, divided in Engineering Groups. Some of them, like the one I am part of, are formed by several engineering teams, some of them called Working Groups. Core Development is formed by four:

• Kernel
• Power Management
• Security
• Virtualization

 You can find more details in the Core Development wiki page, at Linaro Wiki.

These first few weeks I have gone through the natural landing process, meeting my colleagues and managers, knowing how we operate, learning about my responsibilities, the work engineers are doing, the plans for the future, analysing our internal processes, etc. Nothing unusual in these cases.

In July I had the opportunity to attend to the Linaro Kernel and Power Management Sprint, hosted by one of our Members, ST, in Le Mans. It was a very interesting week.

Linaro Connect

My following event will be Linaro Connect, in San Francisco, USA, in September. Linaro Connect are the events where all the Linaro employees meet. Those of you who are familiar with the Ubuntu Developer Summit knows what I am talking about. Linaro Connect takes place twice a year in a different continent and it is also an opportunity to have a direct contact with our Members.

Factory as a rolling release: openSUSE development version

A few days ago it was announced that Factory moved to a rolling release model. So the first step of the 2014/2016 plan has been completed. I was very happy to see that the openSUSE team could lead the execution of this relevant step for the distro in time. The Development version of openSUSE is now a reality that not just can increase the overall number of contributors, but also bring significant innovation to SUSE Linux Enterprise integration process. Congratulations. I am very proud of being part of the team. I will always be.

I would like to specially congratulate Roland Haidl, the Director of Communities at SUSE. The most important (and hardest) thing you can get from a manager is trust, and the openSUSE team had it from him to build a good team, support the changes the team went through back in 2012 (tough times), stand strong behind the new strategy defined in 2013 and support the team during the design and execution of this first milestone. And he did this without making noise, letting the results speak. A management handbook success.

Personal challenges

On the personal side, relocating has taken most of my energy the last two and a half month. But I have managed to do/plan other things.

LinuxCon Europe

I am part of the LinuxCon Europe Content Committee. The last few days I have been evaluating, together with my colleagues in the committee, the abstracts presented. I has been an interesting work

LinuxCon Europe have very promising keynote speakers but the whole program will be filled up with first class contents.

Sometimes you never know what lives will bring you. I was invited to be part of the committee before joining Linaro. My work now is very related to the Linux Kernel and suddenly, last week, Linaro becomes a Linux Foundation Member. I do not want to think too much about coincidences vs. destiny but....

Akademy 2014

This year Akademy has moved to September and the dates collide with a personal compromise (a wedding) and the preparations for the Linaro Connect so I won't be able to attend. It will be the first time I'll miss it since 2005, when I attended for the first time. I am very sad about it. I tried but...

And it is specially sad for me because the new Treasurer will have to present the financial report about the past 2013, when I was the Treasurer. Being there should be the right thing to do. But I simply cannot make it.

I already missed Akademy-es 2014, that took place in Málaga and was organized by my former colleague Antonio Larrosa and sponsored by my former company, SUSE. I am not running away from KDE, I promise. The Calendar is working against me, that's all.

TEDxLaLaguna

I am a TED video consumer since some years ago, not many. Suddenly, I received a mail from a colleague at college giving me the opportunity to start.....and at home, in the Canary Islands.

Of course I want to try!

So in October I will be in Tenerife giving a TED talk in the local event TEDxLalaguna. Obviously I am already preparing the talk. Let's see how it goes.

As you can see, it is going to be an intensive year, after all.

Opening doors

In a previous article I wrote about the end of a professional (and also personal) cycle. Today I want to announce the new journey I am starting.

A couple of weeks ago I relocated to Cambridge, the original, and from now on, the one and only :-). A new professional and personal project has brought me here. Linaro was so kind to make me an offer impossible to reject, becoming the Director of Core Development. I will explain in a coming post what is that about.

Linaro is a non profit organization with several corporations as patrons (Members) that has as an original goal to make ARM a first class citizen within the Linux Kernel. Four years after its foundation, its success in accomplishing this mission is clear (currently is the third contributor to the kernel). Now it is about achieving new goals together with ensuring the original one.

So after a period in Nuremberg, the beer capital, and a few months in Prague (boy, what a great city), I start a new episode in a new Kingdom.

Sponsored vs supported

Probably the most relevant non technical action that a community executes is events. Most mature communities organize one or several big events in different part of the world with different goals, but one of them is common in every single case: engagement needs face to face relations. We are humans....after all.

In order to organize these events, sooner or later you need a legal organization that provides financial support to these actions. You might not know that, in words of the founders, this was the main reason behind the foundation of KDE e.V. .

And when you want to bring contributors together, most organizations end up having as goal to financially support some of them since they cannot afford it:

• The trip is expensive since they come from the other side of the world.
• They come from countries where the cost of the trip or accommodation represent the salary of a year.
• They are students, so they have little income.
• They have family and they cannot afford the expenses derived from being a week far from home.

There are many more use cases.

So one way or the other, most organization that support FLOSS communities dedicate resources for supporting contributors to attend to its main event(s). But if we look closer, there are small differences among different organizations.

Some differences among organizations.

Since resources are limited, organizations try to make sure they support those who have made significant contributions to the project throughout the year. Being supported/sponsored though, have frequently attached an expectation of being heavily involved in the event itself. Giving a talk or helping the organizers are the more obvious expected actions.

The difference comes when making these variables a plus or a requirement for being sponsored.

The process for being sponsored is also different. The tools used to manage the request/reimbursement process and the "amount of support" too. I will not get into those.

There is a "motivational" difference that do not have much impact but that I have always found interesting. Some organizations support their contributors "as a reward" and some do it "as a duty".

The first case means that some kind of "thank you" is expected/required, linked to that support, as usual when you receive a prize. This act of gratitude might come in different forms but usually tend to publicly reflect that support. The basic idea behind it is to justify the investment in order to increase the level of sponsorship the organization gets from donors. It is a very popular approach in other industries/areas and there are a good number of FLOSS organizations that follow this model.

The other approach, the "support as duty", is based on the principle that if you have made a significant contribution, that is, you are part of the community, and since the organization is there to support the community , it is its duty to support you. So the support comes with no recognition as requirement.  No "public thank you" is expected.

Some refer to this as the difference between being sponsored versus being supported.

My view on this last topic

In different countries/cultures, the sense and consequences of "thank you" are different. Also, the reasons that can "invite" you to ask for support might not be fun to talk, or being being questioned about. You might not feel comfortable by being identify as "sponsored". It also might generate some undesired debate about who is being sponsored or why among people that do not have all the information.

Over the years I have changed my mind. Lately I identify myself more with the second approach, which do not mean I am against the first one. It has a point too.

In any case, what matters is that FLOSS organizations has supporting contributors to attend to the community event as one of their main goals.

A request

If you are not very familiar with how Free Software is developed, all this might sound strange. Investing money in paying trips and accommodation to go to an event to have fun with no or very little deliverables in return?

When thinking about donating to a community project or sponsoring it, ask for this particular topic to the Board of the organization behind it or the coordinators of the travel support program. You will be surprised by how important is this topic for them. They will provide reasons that, I am sure, will satisfy you.

For me, and many others, is one of the main reasons why these organizations deserve to be sponsored. Face to face meetings are essential to build a healthy community or ecosystem and many people have no way to attend if third parties do not sponsor/support them.

Training programs for developers in FLOSS companies: a need

My Experience

When I started with Free Software, there was a need for training people in the new tools that were emerging, not just to users, but also to professional that came from the proprietary world. There, the formal learning culture, through certification, is well established. Due to the business models around the delivery of technical information from soft companies to its channel and customers, investing significant amount of resources in these certifications programs was justified. For professionals, it is a way to improve their curriculum and skills.

Before embracing Free Software, I developed my career in the training sector so I made a living trying to solve this problem for companies that were in the process of discovering Free Software.

In the FLOSS world, these investments is not seen as a "requirement". Although the Free Software commercial space is getting more mature and more and more companies provide these kind of trainings, the general mindset is that you learn by doing, that the code and resources are out there that the formal training is not worth it due to its high cost, that Free Software is a learning environment by itself and that, by simply providing "learning time" to your employees they will develop the skills and learn the concepts they need. It is the typical "engineering innovation" kind of culture.

At a management level, the culture of getting training is solid, but many Free Software companies fail in spreading that culture to the technical level. In my 15+ years as professional I have seen very few companies that takes seriously the improvement of employees skills through training, specially in the engineering area.

Training program

Like when leaning a new language, in order to improve your technical skills, formal training is needed, specially at two points in time:

1. At the very beginning of your learning process, when you are facing something "new".
2. When you reach certain level where improving is not a matter of practicing any longer. It is the case when you make yourself understandable but need to express properly.

In the same way professionals put effort in being efficient in their everyday tasks, it is smart to be efficient in learning new concepts, developing new skills. Formal training in the first case is about that.

In the second case, in my opinion, there is no substitute for formal training. There is a point in which your investment in "studying" is less and less effective, reaching a point in which investing effort in "improving" is not perceived as worth it anymore. Internal training should cover this second case.

Despite its cost, investing in having junior developers formally trained by senior ones is worth it.  Since nobody is senior in everything, seniors become juniors at some point and the other way around. So having regular training sessions covering the first case (introduction to topics) given by employees have interesting secondary benefits.

For the second case, I always recommend going for external trainers. Even in the case you have the experts at home, bringing external people always adds value, a different vision. It is important also that that person is not just a good professional, but a good trainer. It is not so common to find both skills in the same person....at home. If you have one of those.... send him/her to train your customers, not your employees. You will get a higher return.

Do not forget to evaluate and reward your internal trainers. Provide them training also, so they become better trainers. This actions should be part of a more general designed path to increase the number of engineers within your organization that can be successful facing customers and promoting the use of your products and technologies in events. It is what I like to call Engineering Marketing.

One of those secondary benefits you might have not think about is the technical documentation generated for these sessions. In some cases, specially when you are training in technologies or products your company develops, these material are a perfect base for the technical documentation you provide to customers. You can eat you own food also in this area or, at least, design it to give it an early try.

Technical support engineers and presales ones are used to "making themselves understandable". When thinking about creating or improving such a program, think about them as potential trainers. If you have technical writers in the company, involve them too in the material generation. Yes, it increases the cost of the program, but it increases the outcome too. So instead of focusing only in the cost, try to find ways to translate part of the output to your customers too, so the investment is also worth it from the "sales" perspective in the short/mid term.

Some tips about the training sessions.

In my experience, if your company is young, these sessions should take place on Friday, after lunch. It creates a good atmosphere during the less productive time of the week. It is the "fun time". If your company is a more senior one, it is harder to have a significant number of attendees on Friday afternoon so Thursdays afternoons, at the end of the day, would be the best option.

It always come a question when designing these sessions. Should they be part of the workday schedule or should they take place after work as optional?

In my opinion, these sessions should not be mandatory but they should become part of the working hours. They need follow up though, so evaluation is needed. There are many techniques to make these evaluation processes part of the learning process itself so they are not perceived as "boring". You also have to module the consequences of "failing" in these actions so you incentive participation. Having extra sessions for those who do not accomplish the goals can be a good compromise.

Who can you talk to you about this?

There are two people that I recommend you to contact if you want to know about a successful experience in having seniors training juniors as part of the organization culture. They are Miki Vazquez and Gonzalo Aller.

If you do not have a well established training program within your engineering dept. these two people might help you from different points of view: Paul Brown and Roberto Brenlla. They might help you to design and follow up a technical training program, in collaboration with your HR dept. and your technical managers.

Do you know other professionals or companies who are driving successful internal training programs for engineers (employees)? If so, please let me know. I would appreciate it, and some readers too.

Closing doors

Yesterday was my last day as KDE e.V. Board Member. As you know I have been the KDE Treasurer since April 2012. I will keep being part of the Financial Working Group so I will be able to help my successor during the landing process and in the future. I still have some leftovers to finish (reports) and I plan to write a couple of posts about our numbers, so you all know what it the situation of KDE e.V. in general....healthy, by the way :-) It is being a soft transition.

KDE e.V. is in the right time to be ambitious and heavily increase its resources to support KDE community. Several decisions have been made in this regard and they will be executed during this 2014. The financial situation is healthy enough to afford some level of expansion. So I think it is time for somebody else to come with energy and enthusiasm to drive these changes the following months/years. And we have that person so.....

KDE e.V. is a solid organization, well managed and with a Board that takes the financial area seriously. It has been a pleasure and a honor to be part of the Board.

On the other hand, my relation with SUSE will end this month. Working on openSUSE, an specially building and leading the openSUSE Team, has been a great experience. I wish them all the best, specially in their current main task, turning Factory into a "usable" rolling release by changing the development work flow/process. It is a goal with a high impact for openSUSE.

 

openQA has a nice present, a tremendous potential and future, not just from the technical but also from the business point of view. For those of you looking for a great place to work, consider SUSE. It was for me.

The last few weeks I have been temporary living in Prague. I love this city. I am not attending to openSUSE Conference (I am sure it will be a great one) and I am not sure if I will be able to go to Akademy-es, which is a pity since it takes place in Malaga, where I lived for three years, and it is organized by one of my colleagues, Antonio Larrosa. I plan to go to Akademy in Brno though.

As you can see, these are times for changes, after around two years putting my best in KDE e.V. Board and SUSE/openSUSE. I have no idea what am I going to do next but I am sure it will be exciting so I expect an article soon called "Open Doors". Otherwise....I will not know what to do with so much time, or maybe I will... write more posts. :-)

systemd analysis: a personal perspective

I have looked with passion the systemd case since a little more than two years ago. As some of you know my number one passion is innovation, sometimes I think than even more than freedom. From that perspective systemd is a great case for analysis.

To me, systemd is the confirmation of the existence of a establishment in the Free Software space. In early stages, yes, but is already there. People that changed the world once and, after being so long part of the solution, are little by little becoming part of the problem. Also about people that joined in the late nineties or first years in the XXI century this movement and know no other reality but the one they are living in. Many of them, from the innovation perspective, are nothing but qualified followers of the first group.

Do not give me wrong, I am not trying to be disrespectful or play "the smart observer" role here. I might be one of them. It is not up to me to judge this. Please take in consideration that the existence of these groups of people is nothing but the normal consequence of.... success and getting older. It is hard to scape from nature, right?

As usual in these cases, not just Lennart, but many of those who supported him, also those who sponsored these efforts, has suffered all kind of attacks. Sadly not just for technical, I mean ATTACKS. Even journalists have been involved. Yes, Free Software is also mature enough to have "yellow (technical) press" associated, political and business interests and people in different communities willing to use them against anybody who threaten the current status quo.

But this is something you have to be prepared to assume if you want to succeed in bringing key changes in mature environment. And Free Software is becoming a mature environment.

You cannot expect to change the current status quo if you are not able to assume heavy criticism. You cannot succeed any longer just by talking, trying to convince you are right from a technical level, being nice, transparent and open to get feedback. Playing as a good citizen is a must, of course, but is not enough any longer.

You need to sustain your effort for a while and have enough support (yes, financial too) to fight back while keep walking in the direction you believe in. If you are not strong enough, if you are not willing to make sacrifices, if you cannot or are not able to ignore the noise, the attacks from the establishment, no matter how popular they are or were, don't try it. Try instead to innovate in unexplored areas. It is
easier and more pleasant.

But is worse for all of us in the long run, I think.

To me there is a very interesting aspect to remark. Even if you want to change a pillar and you are ready to fight the dinosaurs (which is not a condition directly related with age, by the way), you need to have financial support, specially in key moments, to be able to execute your plans despite heavy criticisms. systemd would have never been successful without it, I think.

I cannot judge from a technical perspective if systemd is a step forward, one of those architectural changes that we all will regret or a very expensive road before getting a good solution. This post is not about technical evaluations or predictions. This post is about me believing that Free Software is still (also) about innovation, not just in new areas, but in those aspects that brought us here too.

No, we are not in the finish line. No, many of those who brought us here or are relevant today are prepared to take us to the next level. As in many other industries, the main forces against evolution are internal ones.

"If it works don't touch it" Or "Disrupting changes come through iterations" were popular statement among those who are not relevant any longer.... or will become. Should become.

Thanks Lennart, your sponsors and supporters for succeeding.... or die trying. My respects. I hope the future of Free Software will be in the hands of people like you.  we need it or something else will replace us. Maybe that is not bad either.

Two final remarks....

• Please Lennart and colleagues, make sure systemd works very well. I do not want to eat my words in three years. There are some people out there willing to see me swallowing them ;-)
• I regret writing about this today instead of some months ago. Now it has been too easy.