//log//

Earlier last week, my team and I attended the thinkproject! group technology summit. Taking place in Berlin during November 13 to 15, this event focussed on getting technical teams throughout the whole group together, getting people to know each other and helping strong teams getting started building great products together in a collaborative way. As a tech team and a company, we’ve been into this since 2011 so such an event possibly was extremely overdue, and in the end, for a first attempt, it worked out pretty well…

55 attendees, 11 agile teams from 8 locations all across Europe – at times, looking at the sheer figures helps putting things into context and seeing yourself as part of a bigger whole. Looking at these figures, too, and understanding that a load of these people especially all across the different teams meet in real life for the first time, getting this to work seems quite a challenge, and consequently, a couple of months (of figuring out location, goals, agenda and finding an actual date that works for most people) went by, pushing this event from a planned mid-June schedule late into 2017. Looking back at the event however, it was time well spent:

• Initially, all the teams had the chance to introduce themselves, to tell their story, outline their skills and describe some of the tasks and challenges they are supposed to deal with each and every day. This was impressive both seeing the bandwidth of technical skills and experiences available across the teams – and, to some point, also seeing that there is a a set of problems and challenges most of the teams have in common these days.
• One of the original ideas of this meeting was to be a huge cross-team hackathon to enable experts from different teams to hang out with each other and work on some prototype solution they could agree upon in advance. This wasn’t mainly supposed to provide any “usable” results but rather to get people to know each other, to work each other in a creative and open environment lacking the pressure of everyday project and product development work. This worked out at least to some degree.
• Asides this, late in planning we decided to also offer loosely structured workshops to allow for all those who aren’t deeply involved into the hackathon to have expert exchange on interesting technical topics all attendees were allowed to vote on in advance.
  This was pretty interesting as it resulted quite in quite a range of topics worth discussing as well as in a range of topics where people across the teams found the need to keep on working together in the future, such as usability, microservices standards or container orchestration.

In the end, there’s a load of room for improvement – there always is. But I both had a bunch of very interesting and inspiring conversations and watched at least my team involved into just the same with guys from other parts of the organizations, so overally I suppose the no.1 objective of this meeting – getting people to know and to somehow work with each other – has been met. Two noteworthy insights I made all along the lines: Looking at the workshops that took place, these were surprisingly heavy on topics such as microservices, container deployment / CI, testing, logging – altogether maybe topics closer to DevOps or the border between development and operations rather than just mere development or pure operations issues. There seems to be a need for these things in day-to-day work even by now.

Plus, something that got obvious once again: Though there just was a handful of people in an “operations” or systems engineers role, it’s always stunning to see the sheer amount of resources and infrastructure they operate. In times of public or *aaS cloud offerings, people tend to forget that providing reliable, stable infrastructure transparently to developers and business users is a tough and demanding job, something people should consider in their daily work, not just during SysAdmin Day.

All these things happened in Berlins betahaus barcamp arena. As far as I learnt, places like betahaus served as an incubator for a lot of Berlin based tech startups, and even though I wouldn’t want to work in such an environment day-in, day-out, it surely was interesting being there, especially knowing that a load of all this startup type companies are about a certain kind of technological culture too. This seemed challenging and in some way just right for a larger structure getting started in finding a shared, common culture for technical teams that seem to come from completely different technical and organizational backgrounds. More than sure this is not something that happens all of a sudden, not something that gets done in course of 48 hours of conference. But it’s a good and important first step, and it always needs a first step…

Personal liner notes

Talking about first steps, I feel the need to add a more personal point of view on that: The few regular readers of this page might have figured out by now what my day-to-day business looks like. A load of my posts at least during the recent years have been about work-related things even though I mostly stripped these things of their actual context. In this case, I felt like making a one-time exception from that, to get into this “first step” thing from another point of view: If you work in a 9-to-5 job optimized towards maximum income, best career opportunities, best chances to retire rich at early ages, you’re possibly pretty easy when it comes to moving around and leaving temporary professional engagements behind. If you, however, dedicate a substantial amount of your (working/life) time to a “project” for as long as almost half a decade and counting, you possibly can’t avoid getting a bit more tied to, enthusiastic about what you actually did. From that point of view, more massive changes in a corporate culture, such as being “acquired” by a former “competitor”, might seem barriers almost impossible to overcome as they seem to replace a slow-paced “organic” process of perpetual change by way larger, way more fundamental changes happening all at once. This, of course, influences the way work is done, which in turns will have an effect on any achievements made before that.

Is this threatening? Well…. maybe so, but only from an emotional point of view. Being reasonable here, the biggest “threat” about this seems to come from the idea that, in any other way, business just would have continued as usual. Let’s face it: Massive change is and will be here in any way. Especially in any business related to digital technology, having been there for 15+ years is quite a time. A load of things actually do have changed during these days, and they still do.

Back when we used to grow as a company, digital technologies weren’t that widespread within our special domain – large-format drawings were still stored in HPGL files if at all, and rolling out paper prints to various construction sites and other participants all around Germany was an important part of our day-to-day business. Now, in the late 2010s, this has considerably changed. Digital technologies and tools are on their way to become first class citizens in our domain just as well as in most other fields of business and industry. What used to be a niche market back in our days turned into a playing field for large players with large budgets and teams, ready to provide the customers with their ideas of digital processes as well as the tools suiting these ideas.

Both of these things – new ideas poured into the market by new players and the overall process changing along with new tools – might make some of our current services and solutions completely pointless in near future while at the same time customers will start voicing all new requirements and wishes we so far don’t even think about. Likewise, “new” (at least for Germany and some parts of Western Europe) process approaches such as BIM are looming on the horizon, maybe with the potential of being disruptive technologies, of being to our domain what “Uber” is to taxi driver business. We’re better off dealing with that sooner than later.

Adding to this, of course, managing infrastructure becomes drastically easier. When we started, managing loads of infrastructure more or less well was an important key to success. These days, this doesn’t matter all too much anymore: If you want, companies such as Amazon or other *aas providers will meet your storage and computing resources needs at acceptable costs and with a minimum effort required on your side. If you start over now, you can go quite a while being way faster than any other structure doing the same work yet having a long history of technical infrastructure to handle with. All these changes are here, and these aren’t changes in structures of business operations – they’re changes in the structure of a business domain, of a whole market segment in the age in which things become more and more digital at an increasing speed…
>

From this point of view, the Tech Summit 2017 was an important and inspiring event, as it pretty well showed what, in some ways, was to be expected: This structure has quite a skilled (and for the most part active) technical team. There are quite some people throughout the teams very well aware of the fact that competing on fairly low levels and re-inventing the same wheel doesn’t make much sense. I’m pretty convinced these guys will be able to successfully take on all these challenges – if they get the chance to, if they, or better “we” can find a way to make them focus on what’s important, to avoid spending time and energy on solving all the same known problems over and over again and rather get all these folks aligned to act as “one”, to make sure they can do their best in addressing todays and tomorrows challenges. We do have visions on how this might look three to five years from now. Let’s stop starting and get going.

Filed under: