Dear software manager, working in the open for the very first time? Face the challenges (II)

~ toscalix ~ 3 Comments

This post is the continuation of the previous one, titled Dear software manager, working in the open for the very first time? Face the challenges (I)

Focus shift

I understand the transition that a front line manager needs to go through when moving to work in the open as a personal journey, mostly because the challenges described in the first post of this series, specially those related with personal values, have had a significant impact on who I am today.

I believe that working in the open long enough will charge not just the way you understand your work but other aspects like your personal relations, your view as a professional… you mindset. The key question to me is how to drive that change in a way that you do not use trial-error as the number one technique to learn, knowing that, unlike in the case of most developers, as a manager your mistakes have a significant impact on those around you.

I strongly believe that habits change mindsets, not the other way around. Which translated to a job means that in order to adapt to a new way of thinking it is required to work in a different way.

So in my opinion, in order to succeed faster as a front line project manager in the open you will need to embrace new habits as a manager. And I know by experience that the transformation process is faster when you realise that it is not just about changing the mechanics of your work but also about shifting your focus.

This is the core idea I want readers to take away. It is not just about adapting what you were doing already within your company, but also shifting the focus of your work to make a meaningful impact in a different area.

From autonomy to alignment

I created a model that helped me to understand where I was, what I needed to focus on in order to succeed as a manager, as a team, as an organization or project. I will provide some information about this model since so I can use it to describe that focus shits I mentioned before.

My personal model can be summarised in a cycle with four stages. I have written about this before, by the way:

toscalix management model
toscalix management model

I came to this model through a bottom-up approach, as a result of my experience working in open organizations. The structure in these four stages came from two key popular references:

  • The motivation model described by Daniel Pink in his famous book Drive.
  • The challenges described by Nilofer Merchant in her book The New How, when moving from strategy to execution in order to innovate. Those challenges many organizations go through led Nilofer to the description of the air sandwitch problem and how to approach it: alignment.

You can find references to both books in the Reads section of this site.

In corporate/in-house projects, front line managers mostly focus on what in the model refers to autonomy. They are perceived as successful when the people they manage are efficient which build trust on development teams, who get more room to work their way. Managers can then focus on effectiveness, risk evaluation, and mitigation activities, etc. increasing their impact and allowing them to help the engineering teams to a greater extend.

In my experience, the initial focus of most front line managers when working in the open is learning the new mechanics that would allow them to increase efficiency first and effectiveness later on of those around them. That might not be a bad approach since sometimes in Open Source projects, efficiency is a significant issue. At the very end, we all want to add value since day one, right?

But often this approach lead those managers to become the project escribe, doing  non-technical work with lower impact they are used to: driving meetings, documenting, etc. I have seen many people in Open Source, even other managers who went through the same process, justifying this approach as necessary to learn the new culture while adapting to the new environment. In other words, you play the role of a junior instead of a newcomer, living in first person a tough contrast when comparing the role you play in the open with the one you play within their companies.

When working in the open, I strongly believe that the key point to significantly shorten the time frame required for a front line manager to add real value to the project is to put emphasis from day one in alignment.

In most companies, this is the focus of more senior managers, so front line managers partially lack the skills and experience required to make a positive impact in alignment early on. At the same time, working in the open represents a unique opportunity to develop those skills and experience without many of the constrains and responsibilities associated to a senior management role.

Execution alignment based on the project goals (shared vision) represents one of the outstanding challenges in Open Source projects, so the main opportunity for a front line manager to add real value.

pjm_role_closed_vs_open_projects

Back to the personal journey approach, there are several habits that managers will need to change in order to get the right mindset to succeed. I will focus on the two I think are more important, and tough at the same time.

Key habits to change

Back to the personal journey approach, there are several habits that managers will need to change in order to get the right mindset to succeed. I will focus on the two I think are more important, and tough at the same time.

The first one is the management style. As a manager you will need to transit towards coaching as the main style. If directive is the default one in your organization, your journey will be longer and tougher than if your style can be identified already as affiliative. There is plenty of literature about management styles but sadly not much (for this context) about the next habit.

The second one is transparency, which has different requirements and implications for a manager than for a developer working in the open, since they hold a different responsibility within their organizations compared than in the Open Source projects towards their managees.

Let me clarify an interesting aspect of transparency.

There are restaurants where the kitchen is exposed to the customers. We all can see if it is clean, if there is a good working atmosphere, who is the chef and who clean the dishes, etc. Many people feel better in those restaurants because for them, selecting a restaurant is not just about getting tasty food at a reasonable price from a good service.

But is it exposing your kitchen being transparent?

Out of what the experience as a customer, an accountant can tell more meaningful information about that restaurant by looking at the numbers that somebody like me can tell by looking at the kitchen, since I have no clue about cooking. Transparency and exposure are not the same thing.

A key goal as a manager working in the open is to figure out how to drive a symbiotic relation between the organization the team belongs to and the Open Source project and their participants. Transparency at a personal, team and organization level is so important that should be practised since day one. Again, transparency and exposure are not synonyms.

Conclusion

Working in the open involve new challenges that requires a different mindset to be successfully faced by front line managers moving from corporate to Open Source projects. They will need to develop new habits and the most effective way to do so, in my view, is understanding since day one that your focus will need to move towards alignment instead of insisting in autonomy, according to my mental model. With that in mind, my advice is to pay special attention to those habits that will lead you to become a servant for your managees, promoting transparency by example…

…together with a good doses of patience and tolerance to public criticism. 🙂

Dear software manager, working in the open for the very first time? Challenges (I)

~ toscalix ~ 3 Comments

Warning: these two posts are a “Lessons Learnt” kind of post, so there is a grandpa kind of smell on it that I am not sure I am comfortable with so there is very little science.

I’ve got lately a few questions from managers about different aspects involved in the transition to working in the open when coming from a traditional corporate environment. This post and the next one are an attempt to answer some of those questions.

In this post I will focus on describing some of the challenges any manager will face and a second one will deal with how to face them.

I will constrain my comments to management aspects, ignoring as much as possible the leadership topic, although they are related. These two articles target what I call front line managers, not senior managers (managers of managers) nor executives. By front line managers I mean those that is in daily contact with developers and that represent, in a top down view of an organization chart, the lower management level. It is true though than many of the ideas you will read  might be valid to other profiles. You tell me.

Challenges

When moving from managing software projects/teams in classic corporate environments into Open Source  (FOSS) projects, there are several new challenges any front line manager will need to face. I group them here in four categories:

  • Challenges derived from the fact that Open Source projects are public and open.
  • Challenges related with the FOSS culture which has some unique characteristics.
  • Open Source has a project nature different in many aspects from the service/product nature most companies have.
  • Working in the open implies new challenges from a more personal point of view, involving values, motivations, etc.

Feel free to add more challenges that those named below. I would go over them.

Challenges: public and open

Some of the challenges corresponding to this category, in my opinion are:

  • In open environments like Open Source projects, no matter if they are community, company or consortium driven, technical leadership is as relevant (or even more relevant) than any other type of leadership, including business leadership.
  • Open Source development and delivery are all about distributed teams and, in most cases, about  multicultural teams.
  • Every aspect of the project needs to consider asynchrony by default. I find this challenge one of the most difficult to understand early on for those coming from corporate environments, even from big corporations, since managers tend to be familiar with concentrating specific roles and responsibilities per site/location, even when high availability is a business requirement.
  • When working in the open, you not just represent yourself, but also the organization you belong to. This is magnified when talking about managers because very frequently they are also perceived as the voice of the team they manage, which is not necessarily the case every time.
  • Front line managers are familiar with dealing with private and confidential information, but working in the open brings new challenges in this regard. This seems obvious. But what in my experience is not so obvious, because it is very often not part of front line manager’s responsibilities within their companies, is to deal with the preparation, communication and consequences of making corporate/internal information public, for instance. There are other interesting cases to consider in this regard.

Challenges: culture

  • In Open Source, openness is a given, although depending on the governance model of the project, there might be different degrees. The same applies to sharing.
  • One of the pillars that has made Open Source so successful is code ownership. If you develop it, you own it, which means that you are expected to maintain it. I have written several times before about how important this point is for the professional and personal growth of any developer. I know a few that, by the time they turned  20, they were already maintaining software used by thousands of people. That is something no college will teach them… nor most companies, sadly. There are still many so called senior engineers that haven’t dealt with the consequences of their own code or the one done by their teams for a few years. The agile movement, through promoting the micro-service architecture, has recognised how important this point is. Development teams are in charge of maintaining what they deploy in production. Still, Agile has not reached the level taken in this regard by Open Source.
  • Standardisation through adoption. This concept is significantly different in corporate environments. The success that Open Source is having though is slightly changing the approach to standardisation many corporations have. There is still a long way to go.
  • Consensus is as important as efficiency in Open Source projects. Some people talk about consensus driven development when referring to Open Source development to highlight how important this aspect is. Corporate managers and executives very often perceive Open Source development as significantly slower compared to developing in-house, which technically speaking might be true in some cases. They underestimate though the benefits that consensus has within a project overtime, specially when talking about the motivational aspects, when dealing with complex problems, interoperability, etc..
  • Documentation always beats meetings, always. I go even further. Meetings are so expensive and precious in highly distributed environments, that front line managers go through a lot of pain until they learn to focus meetings on discussing instead of reporting. This is a fundamental disagreement I have with the stand up concept, by the way. And I am not the only one. Reporting should not be part of any meeting. Period. Document and read reports up front.
  • Open Source is all about specialists (aka rock stars) instead of about teams. Front line managers have a particularly hard time dealing with “unique personalities” in the open. The tools they’ve learn to deal with them are very often not valid in the new environment. As I have written before, the team culture is one of the assets that corporations are bringing into Open Source.

Challenges: project nature

  • Open Source projects are mostly related with R&D, technology or tooling development and, in some cases, specially in company driven communities/projects, about pre-production (early productization stages). They are not about developing products or services which is what corporations are mostly about, even when dealing with R&D. This difference requires, for example, that front line managers pay constant attention to value-capture-and-return cycles between the project and the company.
  • Within Open Source projects, the relation among organizations is not common to many managers coming from corporate environments. Other organizations are treated as partners instead of customers, even if they are service providers or suppliers. In a similar way somebody you work with is a peer, even when talking about members of their teams (managee).
  • Looking at delivery, in Open Source is frequent to release features when ready, on a time based release cadence, which helps to coordinate many different parties. Within most organizations, not even R&D delivery is managed this way. Lately, rolling/continuous approaches are becoming popular among FOSS projects. This way of understanding delivery is very often tough for managers risen in the “deadline drama” culture.
  • When taking decisions in the open, front line managers need to adapt to the fact that developers think about the project as much as they think about the company they belong to. Sometimes even more. Who pays your salary and what for are common question among those managers who do not fully understand yet the environment they are working on. They get the perception that people tend to forget the corresponding  answers after a while working in the open.
  • I always ask managers working in the open about their definition of success for the teams they manage. By their answers I learn a lot about the transition stage they are in. Defining success, even in FOSS projects with a clear shared vision, might become tough. And it is so important to have an agreed definition by every team member…. In general, a definition of success for a team working in the open should consider at least these elements:
    • The project/community.
    • The company or organization that pays the check.
    • How is the value capture-return cycle defined for both, the company and the project.
    • Additional aspects that motivates the team.

Challenges: personal values

  • Front line managers, specially those with little exposure to customers, are not familiar with every aspect involved in professional reputation. It is a relevant concept when your work is public and can be directly associated to you. It is so powerful that it is easily mistaken with the most negative aspects of “ego”. Senior managers coming from corporate environments understand it better but still not fully. Reading or talking about it, listening to those who has been there, working with them, is not enough to get what is like to be on the other side. You need to cross the river to understand it.
  • Open Source was born out of strong ethical values. So strong that they are still relevant to many. FOSS is now mainstream so most think that those values are disappearing, being relevant only to the “senior geeks” working in some specific projects. I believe though that those ethical values still matter and, in my experience, the longer people is involved in Open Source, the more relevant they become for them, no matter where they come from. It takes time for anybody coming from corporate environments to fully understand the impact some of these values have and their implications in day to day activities. These values tend to to manifest vigorously when conflicts arise.
  • One of the things that everybody learn very soon when collaborating in Open Source projects is that people have “two different personalities” which in some cases diverge: the offline and the online personalities.

These challenges, and many others not mentioned above, will require different levels of attention at different stages of the adaptation/transition process to any manager. So in one way or the other, they will need to develop skills and accumulate experience to successfully face them.

A second post describes some ideas about how to approach these challenges when joining an Open Source project as a manager.

Introducing my new friend: a Slimbook

~ toscalix ~ 3 Comments

Probably most of you will understand me if I tell you I consider my laptop almost like a partner, like my father feels about his car, or kind of. I cannot help but feeling attached to a machine I use many hours a day. So when you have to change it, it is kind of a drama.

It is also a risky decision. I travel quite often and work from home. I have no workstation. This means that I need a powerful and lightweight machine, with high-resolution but also high autonomy, good keyboard and the right combination/amount of outputs… in summary, a good machine.

After a happy journey with Dell, I switched to Lenovo which has been my choice for some years. Not just my former working laptop was a Lenovo but my personal one and my tablet as well.

Why Slimbook

I have been following Slimbook for some time now. As you probably know, they ship a KDE laptop that is very cool, with KDE Neon pre-installed. They have attended to a couple of events I have attended to so I have been able to test their laptops, get feedback from buyers and ask them questions directly. The fact that they are a Spanish company was a beautiful surprise, We do not have that many hardware integrators and vendors in Spain.

But what definitely caught my attention was the fact that they pay a lot of attention to the software. They ship the laptops with Linux pre-installed. Ok, that is not new any more. But they do pre-install several different distros. Now, that’s uncommon. But news do not stop there.

They have created a community of customers that help each other to ensure that you get help beyond their contract responsibilities. They pay attention to this point which makes the pre-sales decision easier, by the way. They also sell peripherals that work on the chosen distro and they welcome tests and reports about them from customers who has installed Linux distributions they do not pre-install.

On the hardware side, Slimbooks are powerful, with a modern look and many cool features.

Based on the above in addition to my KDE colleagues feedback, I decided in October 2017 to go for one. I bought a PRO2 with customised high end components. A machine to work with the coming years.

You need to consider that Slimbook is not a big corporation so they do not have much stock. If you want something special, it will take them some days to ensemble it, test the hardware, install and configure the chosen distro and deliver it.

Evaluation… so far.

Let me start by saying I have no commercial relation with them. I write this post as a way to support the effort Slimbook and some of my colleagues are doing to bring KDE to the hands of Slimbook customers.

The purchase process in my case required some back and forth because I wanted to install openSUSE and it was not by then in the list of officially supported distros. They were kind enough to take the opportunity to install it for me and check that everything worked fine. It did. A different story was the dock station available in their store, which I bought. They reported me they could not make it work at 100% with openSUSE Leap 42.2 before sending it so I ended up not buying it.

So as outcome of this process, Slimbook now supports openSUSE Leap and they do not recommend this dock station to buyers that request the camaleon pre-installed. This was a a huge time saver for me. Also, I was travelling during the arrival date of the laptop. They managed to ship it so it arrived when I was at home, in between trips, the day I requested.

Slimbook demonstrated they understand what customer service really means.

Sadly I completely forgot to mention to them I needed the hard disk encrypted so I had to reinstall the OS again. This time I went directly for openSUSE Leap 42.3. Everything worked out of the box or was trivial to fix:

  • As usual, the high-resolution of the screen provides some headaches when booting the KDE desktop for the very first time (everything is tiny) which is a plus for having the distro pre-installed.
  • I had to go to Yast to finish the configuration of the sound card. Another reason for buying a machine with the distro pre-installed.

On a side note, I will highlight how painful it is to manage resolutions and font dpi when working with a dual screen configuration with a big resolution difference between screens (laptop vs monitor). This is the first time I have a laptop with a very high-resolution screen so it was like going back to the bad old days when Linux users had to manually configure screens, projectors… This has nothing to do with Slimbook though.

As usual, configuring a working machine takes quite a long time. There are so many things to install and configure… I am still discovering small pain points and highlights of my PRO2 in working conditions.

I have written to Slimbook a couple of times with suggestions to consider for their store and future high-end models. Nothing really important except maybe the battery capacity, which I consider short for heavy travellers (not for occasional ones).

This point was  not a surprise for me though. Based on the info provided by Slimbook on their website, I could research about it up front. tlp is something you might consider to install and learn how to manage in order to significantly increase the working time with your laptop while on battery.

I get very pity with the location and number of outputs in every laptop I’ve ever had. I must say they are not too bad on this PRO2. Or maybe it is just that I am usually so annoyed that not being too disappointed this time seems like a good sign.

The laptop has so many highlights that I will not go over them. Take it as a good sign.

Veredict

Do I recommend you the PRO2 with my configuration?

No. My needs might not be yours. You have to get what you need/want. Slimbook allows you to customise your machine which in my case it is a good thing. I considered other laptops from Lenovo or Dell, by the way. I even considered a MacBook.

Do I recommend you Slimbook?

The purchase of a laptop has to be evaluated after a couple of years to be absolutely fair. I am confident about this purchase though based on the customer support I have already received, which is more than what I can say in other cases with well established vendors.

So if you require a good-looking and powerful laptop, you have many options. If you also want to customise it with different components, then the options get reduced. If on top of that, you are looking for a machine with a Linux distro pre-installed, the number of possibilities are small and, depending on the distro you want, close to none.

If on top of all the above, you want a healthy community of consumers that help each other, well supported by the vendor itself, then Slimbook becomes a good option. An if in addition, you want to work with people that understands how important it is your laptop for a professional, the machine you work with everyday, which necessarily means the vendor must provide a good customer support, then I recommend you to talk to these guys. You will find them, for instance, in most major Open Source events that take place in Spain.

As I have said before, the times for hardware/electronic vendors to “fire & forget” are over, or will be shortly. Updating the software and providing maintenance and support to your consumers, way beyond the law obligations, is not just a differentiation factor any more, but a must.

Based on my experience so far, Slimbook gets it.

CIP related work during the second half of 2017

~ toscalix ~ 1 Comment

As you probably know by now, I have been involved in the Civil Infrastructure Project (CIP), a Linux Foundation Initiative formed in 2016, representing Codethink, a founder Member and coordinating the engineering work in two areas within the project:

  • CIP Kernel maintenance
  • Testing strategy and kernel testing tooling.

In the first front, Ben Hutchings, the Debian Kernel maintainer, a colleague at Codehtink, has been labelled as CIP Kernel maintainer until August 2018. Ben has released in December the latest version of the CIP Kernel 4.4.105-cip15 Currently he is working on releasing a new version, including fixes for Meltdown.CIP Initiative logo

During 2017 until a little after ELCE, I have worked on defining the testing strategy for the CIP kernel and coordinating the efforts towards creating a tool to test it, based on kernelci.org. Robert Marshall has been leading the technical efforts the last few months. The tools was finally called Board at Desk (B@D). Some days before ELCE 2017 CIP released first version of the tool, which is nothing but an integration in a VM of the kernelci.org infrastructure that allow testers to test kernels locally in a board connected directly to their machines. There is no need for a remote centralised infrastructure to collect, process and visualise the results. You can read more about it in the B@D 1.0 Release announcement.

A lot of the work my colleagues and I did for CIP got its visualization at the Embedded Linux Conference Europe 2017, that took place in Prague during the third week of October. A couple of articles summarise the activity:

Codethink’s involvement the last few weeks of 2017 and the beginning of 2018 is reduced to the CIP kernel maintenance so in parallel, I have also reduced my involvement to focus more in customer’s work. I plan to attend to the Open Source Summit Japan 2018 to support again CIP activities.

If you are interested in following the work the CIP is doing to bring Linux based systems to Industrial Grade products, I recommend you join the cip-dev mailing list. You can read a previous post I wrote about my CIP related activity.

Akademy 2017: it’s great to be part of KDE.

~ toscalix ~ 2 Comments

After two years absent of any KDE event I was looking forward to see old friends and meet new KDE contributors and supporters. During July 20th and 21st it took place in Almería, Spain, Akademy-es. The following day, July 22nd, Akademy started. I stayed until Monday 24th there, combining my participation at the event with my job. Almería is only a couple of hours drive from my place so there was no excuse this year. I had to be there.626px-KDE_mascot_Konqi_for_KDE_event_Akademy

I would like to start thanking the organisers for the effort and the success of the event. Well done. I am specially happy to see an old friend, Ismael Olea, back to front. We need more people like you, Ismael, to keep the essence of Free Software intact.

Since I haven’t been contributing lately to KDE, I decided to concentrate my participation this time in letting participants know about the transformation the automotive sector is going through and the opportunities that new, open and collaborative environments like AGL and GENIVI open to the KDE project.

The past few months I have sent a couple of e-mails explaining my point of view on this topic, together with a blog post I wrote a few months back. Hence for most my message was not news. I delivered a talk at Akademy-es and a lightning talk at Akademy about it. You can find the slides on the Conferences section of this site.

A few community members showed interest in the topic so we held a BoF. We agreed of taking some steps forward in order to explore the presence of KDE in automotive forums. Once we have the initial tangible results, I will inform about it.

I am pleased with the Akademy Awards this year. All were well deserved but I am specially happy of the one received by Cornelius Schumacher for his contributions throughout many years to KDE. I am specially proud of having shared with him two years at the KDE e.V. Board of Directors, having him as leader (President). The award received by the KDE representatives in the Free Qt Foundation was well deserved too. Olaf and Martin has done a terrific job over the years to ensure Qt remains open no matter who develops it. KDE needs to promote more the relevance of this foundation and the benefits for the entire KDE and Qt ecosystems. Thanks Olaf and Martin.

I loved to see how KDE Spain has gone through a major change in its board keeping the same energy and enthusiasm. Akademy-es was full of new faces and its impact in the overall KDE community keeps growing. Antonio Larrosa, as the previous leading figures were, is well surrounded and supported. I liked the modest but honest recognition we had with José Millán at the KDE Spain general assembly, for his contribution to the association. Good luck to the new KDE Spain board of directors.

I was glad to see Slimbook supporting Akademy-es and Akademy. Take a look at their laptops. They are beautiful and very powerful. Slimbook put effort on the software side, providing good support on Linux to the hardware they ship. It always a pleasure to see companies I hae had relation in the past supporting Free Software events. Opentia sponsored Akademy-es. Thanks Alberto Barrionuevo. I was also pleased with the KDE e.V AGM results and dynamics. Some changes will be introduced to make it even more fluid next year, opening part of its content to the wider community. A good move, I think. Cheers to the promoters of these changes.

I would like to thank Marta Rybczynska for her contribution to KDE e.V as Treasurer. Marta’s dedication has provided stability and certainty. Good job Marta! Good luck to the new Treasurer and the rest of the KDE eV Board.

Thanks to Codethink Ltd, my employer, for supporting me in attending to Akademy and Akademy-es. It is great to be back.

Why to support community driven FOSS events

~ toscalix ~ 1 Comment

FLOSS event offerings have exploded in the last few years. You can find everything from very elite, invitation-only pricey events to small, local meetings that are open to everybody. Almost every company that migrates from being an Open Source consumer to a contributor becomes a conference sponsor, which is positive.

akademy-2017-group-photo

Out there, are the key Open Source communities that constitute the roots of this movement. Even in the cases where they are no longer under the spotlight, some communities still keep the essence of what has made Open Source unique and successful; in some cases for over 20 years, ensuring they have the greatest chances to stand for 20 more.

Events organised by these key communities are all about people, about community, about technology and innovation. Yes, there is space for marketing and business, but that is not where the focus lies or what participants look for. These conferences are not fancy, they do not get much media attention, they do not attract big sponsorship, nor a thousand participants.

But at the same time, they do not have ridiculous keynoakademy-es-2017-group-phototes, booths of companies showing the same things over and over again, insubstantial talks about products with little innovation or preachers about how awesome their CLA based community they are building is. Conferences in which most participants are there simply to work. The kind of conferences you attend with little passion to after a while.

There is a group of companies out there that understand how important community focused conferences are. Companies that realise that these events are not just a key activity for those communities that organise them, but also for the participants as individuals and Open Source as a whole.

In many cases, these companies do not have a direct interest in what a specific community does, but they support them anyway, because they listen to their employees and support their passion, or simply as way of being fair, giving a little in return for the immense value they get out of the Open Source community. It is not charity, it is justice.

But in most cases, for these companies it is also about business, the hard kind of business, the sustainable one.

Professional growth requires you to think out of the box; to challenge your ideas; to listen to others’ opinions; to learn from the mistakes of your masters; to choose who to follow with care, and to put yourself in front of an audience, justify your decision and its consequences for others. In summary, to learn, with honesty and a critical spirit.

By supporting these events and encouraging your employees to attend, no matter if they are contributors or not, you are helping them grow while, at the same time, you are helping those key communities to keep on rolling. As a guadec_2012_group_photoconsequence, you are helping yourself too as an organization.

Three benefits for the price of one, and a cheap price.

I work for one of those companies, Codethink. We are strong in embedded, specially in Automotive. There are plenty of industry events we could invest our money in, getting an immediate value when done right. And we do invest in some. But these community-driven events are still a key part of our strategy. It is good for the business, because it is very good for our people.

In 2017 alone, Codethink has sponsored and/or helped in the organisation of FOSDEM, GUADEC, DebConf, several PyCon events, OpenStack meetups.. . On top of that, Codethink has a policy whereby each employee gets financial support and days off to attend such events. We are not the only company with this kind of strategies. There should be many more though. Obviously for an 80 people company, this is a serious investment. But after 10 years Codethink has demonstrated that this support is not a way of sharing profit, but a core business action.

My colleagues, as well as myself, learn, grow, share, refute, discuss aakademy-2009-group-photond interact with some of the most talented developers (professionals) in the world at these events, taking advantage of an environment that no enterprise event can match. We recharge our batteries, open our eyes, ask ourselves key questions about our work and our careers, about our managers and colleagues, and about our own company. We learn what others do and how they do it, comparing the possibilities their companies provide them to ours. We interact with young developers, reflect on ourselves some years back, getting a different perspective of ourselves and our careers, etc. We grow as individuals and as professionals, so Codethink grows as organization.

It is like a cold shower in the morning. You do not know how good it is until you get dressed.

Obviously Codethink is far from perfect. There is plenty of room for improving these actions and the return we all get out of them, but overall it pays off, no question about it.

So next time you think about your sponsorship strategy and the participation of your colleagues in Open Source conferences, think about community driven events and give them a try. Ask your employees which are the good ones if you do not know them. They will tell you. Even better, attend with them. It will help you to understand the revolution Open Source represents at a completely different level, as well as the profound impact these events have over those who attend.

Like being a parent, you have to live it in order to get it. And Codethink gets it.

 

This article was published at the Codethink Ltd blog on July 31st, edited by Richard Canner.

 

Blog posts about Codethink’s participation at CIP, a Linux Foundation initiative

~ toscalix ~ 1 Comment

The last few months a couple of articles written by me and edited by colleagues at Codethink has been publishedat the Codethink Blog and the CIP blog.

CIP, which is an acronym for Civil Infrastructure Platform is a Linux Foundation initiative focused in creating and maintaining an industrial Grade system. Codethink is a founder member of such initiative and currently is responsible for the maintenance of the kernel and the testing project.

The first blog post, Why Codethink Is A Founder Member Of Civil Infrastructure Platform, A Linux Foundation Initiative explains the reasons behind collaborating in such initiative while the second one, B@D And Forthcoming Challenges is an update of the activity Codethink is carrying on within the project.