Pile of Ideas

By Daiany Palacios. Mostly around IT, Agile, DevOps, Public Speaking, etc. And maybe some other random stuff.

[daianymargarita]

An Ubuntu moment: the day I experienced great motivational energy from a group of strangers

Just a couple of days ago I heard for the first time what Ubuntu really means. It was a kind of realisation to find out that it’s not just an invented word to name a Linux distribution, I have to admit. Never could I have imagined that only a few days later I would experience in my own flesh, what that word means (or at least I believe I did).

I consider myself a self-confident person, and I have been working in my self-promotion with small steps in the past 3 years. But I’ve been doing it kind of intuitively, and since I am always open to learn something new, I decided to give it a try to the #IamRemarkable workshop. A google initiative to Improve the self promotion motivation and skills of women and underrepresented groups. Just out of curiosity, I decided to join when a good friend of mine gave me the tip. I thought it would be good to hear what they had to offer as a concrete advice to improve those skills.

Without intending to go into details of the workshop itself, I want to share here my main learning of the session: The energy that a group of motivated people can create together is a real thing. “Let the enthusiasm and energy of the group be your fuel” is not just some burnt saying or a cliché. It’s real, and it’s amazing.   It might sound like nothing special, but to me it was great to see how the motivation of some individuals created a domino effect in the whole group. Probably because I participated in the session with an open mind and an open heart is why it felt special to me. I was touched by the fact that some people really had a hard time to talk in the group about why they are remarkable, and yet at the end all of them shared their reasons. At the end of the session, everyone had a boosted motivation and I am sure, even a feeling of being amazing and capable of anything. Ready for the next challenge. And all of these great feelings were the result of the humanity of the moment. I feel that I was motivated because everyone else was. As Ubuntu says “I am, because you are”.

My Ubuntu moment gave me the inspiration to spread the word and go out and motivate others. Especially at the workplace. I’ve always been convinced that a motivated team can achieve great things. So now what I’ve got is a new piece of the puzzle of how to achieve or maintain the motivation in a team: by stimulating the individual/personal motivation of each team member, which can be boosted with only a few tricks, like the ones provided in the #IamRemarkable workshop. I feel I should become a trainer. Inspiring people inspires me.

What do you think, should I ?

I created a talk last year to try to inspire people with my experiences. If you made it this far and are curious, you can take a look at it here (about 30min).

If you watched my talk, or if you know me, or have heard me speak somewhere, would you give me your opinion if I would be inspiring enough to become an #IamRemarkable trainer?

Ping me on Twitter @DaianyMargarita

Stay Remarkable! :-)

[daianymargarita]

OKRing myself

I am starting 2021 with my own set of OKRs. And I can’t help to feel excited about it!

It’s not that I am setting goals to myself for the first time, of course. Especially work-related (I created a set of OKRs for myself for my working life), I have always had somehow goals I want to achieve at least in my mind. Although I never took the time to write them down somewhere or to think properly about the right formulation, I’ve always goals for my professional career present in my head, and especially in the past 2 years I have made sure to think twice every move I’ve made, considering if it brings me any closer to the path I want.

And to be honest, I consider I’ve been successful so far in my working life. Or at least I feel satisfied with my job, the company I work for, and chances of growth I’m lucky to have there. So, why OKRing myself? Why taking the time for this? Is it not already too much overkill to apply all of that OKR Theory to your own goals?

IMHO, the answer to the last question is: no, it’s not. Although I haven’t started the competition yet, just being ready at the start line makes me feel energised and confident that it will be worth it.

Of course I can’t tell now if the whole thing was an overkill, but I have a good feeling that it won’t be the case. It was a time-investment on myself, and there is no way this turns out to be not beneficial. Let me explain why I think so.

But before going into that, for the sake of fairness I want to say that one of the drivers of this action was for me also the chance to practice with a real world example all of that OKR theory I’ve been getting myself into lately. Although I had heard about OKRs in the past and the idea sounded interesting to me, I never got really into it until a big organisational change started taking place last year in the company I work for, and OKRs started being introduced as a tool to help the product teams gain a better focus, and somehow give a push to their performance. So next year there will be a big deal of work on this topic coming upon me, and I wanted to get myself prepared as good as I could.

The reasons why I am convinced that OKRing my work life for the next year is a great thing to do, are the following:

I will profit from more focus and measurements of success. I feel that using this method forces me to focus, be clear and precise about my goals. That is basically due to the combination of a general objective and a few very concrete and measurable key results. As I mentioned above, I’ve set goals for myself before but never thought I needed to work on a proper formulation, or on ways to measure my progress. And now I realise, that if I had done that, I would have probably been able to achieve much more, and have a higher motivation due to the feeling of satisfaction coming from tangible progress. Looking back to my past years, I am sure that this would have given me a great push forward.

I now have a clear and precise general vision of my working life. Or at least what I believe is my vision for now, because it might change in the future, one can never know for sure. But for now, I took the time to formulate what is it that I want of my working life, what I consider my purpose and why. And it’s amazing to derive my goals from that vision, it all feels like a puzzle of pieces coming into place. It feels very natural and a logical thing to do. And just having this already is a great win. One of the reasons I feel excited about this whole thing. Now that I’ve done it, I don’t understand why it never occurred to me before to do it. I guess things just happen when they are supposed to happen!

I will learn by doing, with the best example. This will allow me a better jump in the new challenges in the company where I will be working next. And when OKRs are widely used in the company, including HR (which I believe will happen eventually), then I will be experienced already and will be able to help others, which is something I actually enjoy doing.

Considering the particularities of this 2020, I think there couldn’t be a more motivating start in the next working year for me, as it is now. I am really looking forward to start working toward all of those goals and enjoying the rewarding feeling of success that bring the small steps.

2021, bring it on !

[daianymargarita]

Moving a big system to a container platform

So, you couldn't give an effort estimate (you had no idea how long it was going to take) and you hadn't clearly (measurably) formulated the benefits the whole action would bring to the company and our customers, and still you decided to go for it? How could you do that? That's very expensive for the business! I honestly don't get it....

One of the Product Owners of the applications in my department told me that, after a session I held to all our analysts, managers and product owners on the value of moving away from a VM-based runtime architecture, to a Container-based one using the PaaS in-house offering of the company. The decision about migrating had been already taken by the time I joined the platform team. The migration was at a very early stage when I joined and there were still lots of preparations to finish before involving the product teams (we are talking about several applications, in the hands of 7 development teams). So I didn't participate in the decision-making, and missed all the discussions/arguments. On the other hand, I was pretty busy (even overwhelmed) with managing the learning curve I put myself upon, so I didn't have a chance to even question that decision.

But to be honest, even before joining the platform team, when I was working as a system analyst in one of the product teams and heard about the migration to a container platform, I could clearly see the benefits such an action would bring to our systems, to our development process and on the long run, to the whole product delivery. Maybe because of my technical background (I had started my career as a developer after all), or maybe because I had been quite actively involved in DevOps meetUps and conferences and had heard lots of success stories of such migrations, but I just never even considered questioning the decision.

I also found it annoying that some people wanted an estimate from us (the platform team) on when the whole system would be migrated. Luckily our management was clear on the fact that, technically, we could not provide such a number. The reason was: we are not a "DevOps team", we prepare a basis and help the development teams to get into the new container world, write their new pipelines, and basically operate their applications themselves. Our strategy is to empower the teams, to give them ownership of the software they create. So at the end, it would be up to them when and how they would prioritize migrating the applications they were in charge of. Today, almost a year and a half later, the migration is not completed yet. Different factors like changing priorities in the teams, and fixing operational problems we've found along the way with the first migrated applications in production (we are all new to this technology after all!) have led to this state. But it's not in our culture to blame. And so that wasn't either my intention in the session I held, when I mentioned that factors like a steep learning curve and changing priorities in the teams were part of the reasons why the migration is not finished yet. Blaming is something that is just not part of our DNA. So I was kind of blown away when the same person who asked me the question from the beginning also told me he was surprised that I was putting the blame on the teams and their incapability, for the migration not being finished yet.

Anyway, to make the story short (it might be too late by now, but if you've made it this far, please bear with me), I had an "after-session" conversation with this PO where I believe I managed to defend the decision of migrating to the container platform the best I could, and had the chance to hear his point of view. Which left me thinking, and in the need of writing this post...

Now my question to you, who read the whole story:

Say you have no idea how long a big technological change is going to take (because it's new for everyone) and you have not precisely quantified the benefit it will bring to the business (and the customers), but you do know the following:

The theory says, there will be improvements in the runtime architecture, and in general in the software delivery process.

It is possible to do this step by step. The teams won't be blocked completely and there will be still capacity for delivering business features

Would you go for it?

Would it really be so crazy to go for it, as my PO thinks it was?

If you agree with him, then my next questions to you are: 

How else should systems cope with technological advances and improve themselves continuously?

Would you rather hire some specialists who can provide a contract with a timeline and costs you can perfectly plan?

Is a better planning more important/valuable than giving your own people the chance to learn/master the new technology?

If your last two answers are yes, with whatever argument you might have, don't you dare saying you work agile. You still have a long way to go.

[daianymargarita]

Growing into new roles beyond the cloud

(Transcript of an Ignite Talk delivered at O’Reilly Velocity + Software Architecture Berlin 2019)

(Here are the video and the slides of the talk)

Last February my department had a series of rearrangements and everyone was given the chance to change the team. Management asked for our input to restructure as close to our wishes as possible. “We thought the agile coach role might be something for you”, my boss told me. And I replied: you know what? actually I would like to change to the OpenShift migration. 

That conversation was on the phone, so I couldn’t see his face when I said that, but I can imagine his surprise. “Wow, that was kind of unexpected”, he said. And I can understand him: me? A former developer who had spent the past 4 years as a requirements engineer and never had anything to do with operations wants to change to the infrastructure team with an upcoming cloud migration? 

Ladies and Gentlemen, as crazy as it sounds: that was the right move. Both for me and for the department. Let me tell you a few good reasons why.

For the companies, potential talent is practically infinite if they accept that talent can be grown, if new roles can be filled with existing employees not based on their specific knowledge, but rather on their mindset and ability to learn and adapt. Giving people the chance to evolve into new roles is the optimal way to build a culture of growth and continuous improvement. Motivated people deliver great results. 

On the other hand, these are golden opportunities that we employees should hunt and catch. Because that’s the only way to stay competitive. We need to challenge ourselves in order to grow.

Now, having been in this adventure for the last 9 months I can tell you: it is worth it. At first, I felt like an alien in a new world. Today I am still riding up a very steep technical learning curve, but without too much stress, because I know I am adding value to the team as well. Tonight I want to share with you how I have managed to grow into the new role so far, and give you some tips that might help you in your own adventure.

Adapt quickly: by carefully observing the new surroundings, the people, their habits, and the team dynamics in order to take action. When I joined the new team, the first I did was to identify early ways to add value with the knowledge I brought. This helped me stay motivated and not to feel constantly frustrated for being the one who doesn’t know anything.

Embrace continuous learning: and do it step by step. Make a plan with small achievable objectives to manage the learning curve. Be patient. Don’t intend to know everything very fast, because it will only cause frustration. One day one of my new colleagues told me: “Hey, slow down. You are doing fine. Don’t be so hard with yourself”. I had to learn that it’s ok not to know everything. After all I belong to a team and we all complement each other.

Ask around: especially through lots of pairing. Don’t be afraid of asking, but be a good listener. For example, I am often one step behind in the technical discussions, so I make sure they slow down so I can get it.

Have self-confidence: Build it by doing your homework and gathering facts. You have a clear goal and a plan to achieve it which you keep in mind. And on each situation where you get doubts, you go through your plan again, you can do this. You are working on this, so just be patient. You keep repeating it to yourself. Breathe and carry on. 

For me it’s been an intense journey so far. I still have a lot to learn, but I have definitely grown a lot both professionally and personally. I am thankful to Kühne + Nagel (my employer) for giving me this chance, and excited about what’s yet to come.

What I would like you to take home with you tonight is the following: “You can be good at anything you put effort into, you just need to dare”. You can grow into any new role, even beyond the cloud.

[daianymargarita]

The project manager's got some unix skills

There is this "innovation day" every friday at work where everyone has the chance to try out some new ideas, technologies, tools, etc.

Every friday morning there is an open "catch up" meeting where people tell shortly the status of what they're working on, new ideas can be pitched and new groups can be built. There are free drinks, so I usually attend even if I am not working on anything, or even planning to.

A couple of fridays ago while I was drinking my free lemonade there, this project manager announces he has an idea to pitch. He went on, armed with the usual power point presentation with lots of text in the slides and a bunch of bullet points. He wanted to try out the so-called "Cloud IDEs" (e.g. Eclipse CHE and Gitpod) and see if they could really be an option for us development departments in the company.

I had heard a bit about that idea before, and I found it very interesting. So when he was done with his presentation I quickly discovered my hand up in the air. I definitely wanted to give it a try.

Since (surprisingly enough) no other developer volunteered, it would have to be just me and him. I thought: "well, let's see what I can do". Because in my mind, the project manager would practically just sit there and watch. Make a roadmap, write down goals and prepare a presentation.

I was wrong.

The project manager's got some unix skills!

I had met the guy before, we worked together in a project early this year that was drastically stopped. He was the lead manager. The one talking to upper management and giving status reports in Board meetings.

Having known him only in this role before, I have to admit that I was victim of a cliché or stereotype in my head of him being "not technical enough" to try out stuff by himself on this Cloud-IDEs mission we were embarking on. Shame on me!

He was really enthusiastic about the topic. Moreover, he was the one who managed to get Eclipse CHE locally up and running on a minishift cluster, in an Oracle virtual box, on his windows laptop. And I dare to call myself a developer and I didn't get it running on my fancy mac book pro. Shame on me again!

I was fascinated by the passion he put to the topic. He did it all by himself (the installation/setup), he understood about stuff I wasn't expecting him to understand much about: maven, docker, spring boot, shell scripts. I found it really cool. I had to ask him about his background (yes, so curious I was!) And he told me he had developed during his time at university, but never profesionally. He just liked project management more. He codes now and then privately as a hobby but that's it. He was actually the one who said: "I am just a project manager who's got some unix skills".

This story reminded me of 3 important things:

Not to judge people based on stereotypes. I wouldn't like to be judged like that, so I should stop doing that to others. It's common sense.

It's possible to be good at anything we put enough effort into.

Amazing things can be achieved with the right amount of motivation and passion.

Btw, if you made it this far and are curious about the results of our evaluation of Cloud IDEs, stay tuned because I will writing my impressions about that on another post soon.

[daianymargarita]

My first Coding Dojo

There were regular coding dojos in my department until early this year. I never participated before because I was on that phase of my professional career where I didn't have interest in coding.

When I regained interest, the dojos were over :-(. So I took the issue in my hands and went after the original organizers and asked them if we could do one any time soon. And that day was last week. Yay!

I didn't know well what to expect, I must admit I never even googled a bit to find out what exactly the procedure was. I had heard a bit from my colleagues from my previous team last year when they participated, so I knew it was about practicing TDD and pair prgramming and that there was some kind of dynamic that made it fun.

This was the procedure we followed and the rules of the game:

There was a problem to solve ("the Kata") and we got some description and constraints. The idea was to implement a solution in a TDD way.

We worked in a Mob-programming mode, rotating the keyboard every time so everyone would have the chance to write code.

The timeboxes were 5 minutes. Whatever code we wrote and was not commited when the timer beeped, needed to be reverted.

The person writing the code was not supposed to think or participate in the discussion, but just write.

After 90 min (actually a bit longer, but not two hours) we stopped and had a small retrospective about the session.

I really enjoyed the experience. I could identify inmediately the benefits of doing it regularly. In my opinion, there were obvious benefits and some not so obvious ones.

The obvious benefits

A challenge to your development style: you get a chance to practice truly TDD, which is in many cases not done in day-to-day project work. You practice pair programming (or even mob programming in our case) learn tricks from your fellow colleagues and provide some as well. You learn hands-on how it feels to develop that way, and not just the theory.

A chance to do something fun and out of the common daily tasks: you take two hours off from your daily work to sit together with some colleagues and solve a problem in a kind of "Uni style", which depending on the mood you bring, can be a lot of fun while still being a learning experience. It allows you to even "free" or "distract" your mind from whatever tough times or problems you might be facing in your daily work. We laughed a lot together!

A challenge to your "team-working" skills: especially if you are not regularly working in pair. You need to be able to discuss with fellow team members about the possible solution, the approach to take, how to start, if the code adds value already somehow, taking design decisions in a group under time pressure (the short timeboxes), and everything within the boundaries of profesionality of course. This is a powerful soft skill training that is always welcome.

The "not-so-obvious" benefits

A chance to push off your limits: or a chance to extend your comfort zone. Because it can be a completely different dynamic than the regular working days. Changing habits can be really tough and a coding dojo is a safe place to start. Which brings me to the next point.

A safe place to learn: and also to make mistakes. This is the right place to try new things, to dare and do whatever is too scary to try out on the production code, or to dare and try new design approaches every time and see how it feels, if it's a good way to go or not. Exactly the kind of things that are too big or too "expensive" to try on the regular projects you work on. Where else will you get the chance to start on a greenfield every time?

A chance to become a better you: because as the saying goes "Practice makes perfect". And everytime you learn something new that can be only beneficial for your professional life, you get a better version of yourself. Continuous improvement at its maximum!

So, I am guessing I will be attending more coding dojos in the future. And if they are not scheduled, I will organize them myself.

[daianymargarita]

In the Sysadmin-Ops world... without fear!

I made the jump. I am into this now. It's been roughly half a month and I still find myself going through my adaptation plan on my head every morning on my way to the office (just like now) and telling myself that everything is gonna be fine. I can do this. I have no fear!

My main fear: I will look like a fool

There were many things I was afraid of once I realized what I was getting into:

I am the new one and I have no idea. They won't accept me that easy, they will make fun of me. I will look like a fool.

I was never sysadmin. I don't have experience working in linux. There are too many concepts/terms I don't know. While I get myself to the appropriate level, I will look like a fool.

Facing my fears

Well I decided to get my hands to work and do what it takes to fight my fear. I don't want to get knocked down by looking like a fool, so I gotta learn to fight.

Afraid of looking stupid? Just accept that it might be like that for a while, but keep the head up, be proud and self confident that you are amazing. But stay humble. This is what I do.

To not look stupid, I have developed a plan/roadmap on how I will learn all the stuff. What makes me so afraid? The console? Linux admin stuff? So I enrolled myself in an online course and make sure to pair (rather look over the shoulder at first) with me experienced colleagues. Learn by doing.

That there is a bunch of terminology, concepts, etc that I don't know? So I google like crazy and get myself proper books to read while sitting at the bus or train.

No Fear!

With self determination, confidence and a positive attitude, I fight my way through this new world. I will win.

This is the only way we have (btw) to survive in this rapid changing world, being able to learn fast, effectively and with no fear.

[daianymargarita]

The scariest move in my career: "I do devops now"

Bob: (Developer from the neighbor team): Hey Daiany! I see you are closer to us now (he and his team sit across the hall next to my new desk)...

Me: (With a normal-natural smile) Yes, I sit next to M. now (a.k.a. "the devops guy")...

Bob: (With a surprised face) Yes I can see that, but, are you in the devops team now? Really?

Me: (With a smile turning from proud to nervous) Well, yes, I am in that team now..

Bob: (smiling, incredulous) Nahh, come on you gotta be kidding me...

Me: (now definitely with a nervous smile) Yes, look, my stuff is there, I sit next to M. now...

Bob: (With eyes wide open and a slightly higher volume in his voice) You do devops now as well? ARE YOU KIDDING ME?!!

Me: (Confused by his reaction) No I am not. I am in that team now as well...

Bob: (Turns to Tim, another colleague from the "devops" team sitting diagonally to me) Hahaha hey Tim! It seems you guys finally got someone who knows stuff here uh?! .... (laughs and goes away for lunch)

Me: Confused, I go back to my desk, wondering what the hell that was...

Tim: Do you work with Linux?

Me: Nope.

Tim: Haha, of course you don't ! I just wanted to make some jokes! (and turned back his eyes to the screen in front of him)

First day at the new school

That's pretty much how I felt that day, as the new one in the class. That story happened when I moved to the area where my new team is sitting. It hit me, probably ways more than it was supposed to, but I think it was because I had a wild mix of emotions on those days. I had just jumped in the cold water. I had just left a team where I felt like in a family, and we performed amazingly well together, to change to a very different setup, in a field of work where I literally never did anything before. Technically, I had voluntary run away from my comfort zone: I decided to change to the team in charge of the infrastructure automation, a kind of service provider for all other development teams in my department, a.k.a "the devops team".

 Me & DevOps

I started getting my nose in this "devops" thing in 2016 after my previous team managed to implement a delivery pipeline and be the first ones in our department to start doing continuous deployments. I joined the team when the work in that pipeline was going on in paralell to the business requirements and experienced first hand all changes needed to establish such a process, especially the cultural ones. The "devops" mindset, where we as a development team had the possibility and responsibility now of taking care of our deployments and operative aspects of the software we were creating, was a fascinating thing for me. So I started going to conferences and discovering a big and amazing devops community, where I even started telling our own stories.

And all of that happened while I was working as a system analyst at my previous team, a development team. I wasn't coding myself but taking care of the requirements, acceptance tests, design, etc, in close collaboration with the developers and our Product Owner. So I never really took a closer look at all the magic behind the scenes that enabled us as a dev team, to overtake all these responsibilities and change our mindsets toward software operation. That was some interesting stuff that our local "Infrastructure Automation Team" was doing for us (as well for all other dev teams in the department).

That "magic" always seemed interesting to me but I never had (or found) time to learn what exactly it was. I was busy with my stuff as an analyst in my team. 

Until it was time for a change.

 Rescuing my technical skills

Early this year I took the decision to go back to software development (check my post on how and why I came to that conclusion). It was a very good opportunity in a new project with my previous team and I was very inspired and excited about it.

Unfortunately, that project was stopped shortly before we started with the development. It was a dramatic death of the initiative, a real pitty. And that moment coincided with a bunch of other changes in the department that ended up with a big restructuring, where some new topics arrived while others (like mine) where stopped, new teams appeared and old ones were modified.

I had the feeling that it was time for me for a bigger change, somehow. Partly due to the disappointment I had because of the cancelled project, partly due to a gut feeling that told me I should dare and go on a totally different path.

And there it was, the opportunity just waiting for me to dare and take it.

 The cloud calls

It turned out that the so-called "devops" team in my department is planning a migration of the runtime architecture of all our applications from VM-based to Container-based on the cloud with OpenShift. And the management was looking for at least one more person to participate in the process. So I followed my gut feeling and asked my manager if I could join them. Even though I wasn't really sure of what I was getting into.

  An Alien on the infrastructure-team's earth 

That's exactly how I feel now. Management somehow trusted me on being able to get myself to the appropriate technical level where I can truly help the team. Not only on the OpenShift migration, but on all other regular topics taken care of by the team. Well I guess at least I deserve some credit on having been able to convince them that I would be a good choice for the team.

Everyone in the department was surprised for this move, just like Bob, from the story from beginning. At first I was rather proud of being the one swimming against the current, and felt brave and unstoppable. Until that story from the beginning happened.

I ended up in tears on the bathroom telling to the stupid crying girl on the mirror that she needed to calm down. That she is strong and more than able to learn and adapt to new things. I was under an attack of Impostor Syndrom.

Leaving the comfort zone is scary, but I had already taken the step on my own. No one forced me into that, so I had to just face my fears and get my hands to work.

 Challenge accepted

Well there is a loooot of stuff I need to learn now. But I am step by step developing a plan on how I will achieve all of that, while at the same time working on some team-building, getting to know my colleagues and how to get along with them, helping to establish a process that will support the team to achieve its goals till the end of the year. I am learning how to deal with the feeling of being an alien while actively doing my best to "get onboarded" and eventually start adding value to the team, just like a trainee.

I am confident that this experience will bring my professional career to a whole new level. It's just a question of a couple of years. Every day I get more and more conviced that I took the right decision.

Now I am "oficially doing devops" :-P

[daianymargarita]

Back to my roots as a software developer... Why?

Ever since I got my hands for the first time on a computer when I was 9, I knew one day I would become a “computer engineer”. And so I did. My highest qualification is a Masters degree in Software Engineering. I worked as a software engineer writing code for around 6 years. 

Leaving software development...

I enjoyed coding. But I also enjoyed keeping an eye on the big picture. At some point I started focusing my interest more on the requirements engineering part of the software creation. 

On the other hand, for some reason I had the fix idea in my head that eventually there would be a moment in my career where I would stop coding and “move on” to something else... some kind of management/lead maybe? I felt that I had communication/people/soft skills (whatever you call them) that I wanted to use more than I felt I had the chance doing in pure software development.

So when the opportunity appeared, I made the switch. I didn’t become a team lead or a manager, but I stopped coding and became a full time requirements engineer in another team where I never worked as a developer before. This was a new role, with new people in a kind of new world.

I had no interest anymore in source code, frameworks, configurations, etc. I locked myself out of technical details. I trusted the team would find a great solution, which was always the case. I overtook a lot of the "glue work", and I enjoyed it. I felt I was the missing piece in my team. I even had the chance to take a look into what agile coaches do, I started helping them with regular retrospectives moderation, which was a lot of fun for me. I discovered I new side of my professional career I enjoy and I can be good at: moderation/facilitation and public speaking. It sort of became a new passion for me.

At some point I even considered seriously developing my career direction agile coaching. I thought I had what it takes to become a great coach (with the proper training) and I could add a great value to the teams in my department.

I still think that way, but the world kept on turning and with new circumstances and experiences, I started drifting away from that idea. Instead, I started thinking I should probably go back to software development. Maybe not completely switching back, but at least partially as I did for the last 2 years before I completely left programming. I started thinking that I should be able to code again. Pick up where I left off. I shouldn’t loose my technical skills.

Regaining the interest: Why developing again?

Those ideas were circling around in my head for at least half a year (the second half of 2018), until the moment to take the decision became crystal clear to me: my team is about to start the development of a new project, “a green field”. It’s exciting!

My interest is back. And I never thought this would happen! I confess that I am a bit surprised that I am again so interested and motivated to learn and get myself to the status-quo level (I was away from development for the past 4 years), that I decided to take some time to put into words all the reasons why I am doing this.

Here is why:

I shouldn’t loose my technical skills: and I think it’s not too late to gain them back. It was a mistake to lock myself out of all the technical decisions/conversations, but at the moment I simply didn’t have any interest. It was a conscious choice. Eventually I realized that I need to keep my technical skills somehow so I can have a better judgement as a requirements engineer, or even as a tech lead, if I ever become one. And the only way of doing so, is by developing. At least now and then.

I don’t want to loose my technical skills: I decided that whatever path my career is to follow, I would like it to stay close to development. This means, I wouldn’t like to be in a role where I don’t have anything to do with development directly anymore, like an agile coach, a project manager, a senior manager, VP, CIO, CEO (LOL!!). I mean, I wouldn’t like to make a career deep into management. I want to stay as close as I can to the building part of the software and not stay in the planning/coordinating only. It’s cool to be part of the development team, it’s easy to have a feeling of achievement when something works. It’s challenging, but it’s amazing to overcome those challenges. It’s the kind of thinking that maximizes the use of my brain. Which is what I need to stay sane when I get old :P

My team is awesome. They inspired me: they make me feel safe. I am not afraid to fail or look stupid because I don’t know this or that. We have a really good dynamic and I even think I can add more value to the team if I am able to help also with coding now and they when it’s needed. I am sure it will be a lot of fun to build a new project with them from scratch soon. 

Mastering timing & self-organization

It’s a loot of stuff I need to pick up now. The learning curve is steep, I know. On the other hand, I won’t be able to just put aside all my tasks as requirements engineer/analyst now to just focus on development to make it faster. But even if it would be possible, I don’t want to switch back completely. In my department there is this happy possibility of working as a software engineer/system analyst in a double role, focusing more on each according to the needs of the team. And that is the perfect solution for me. I want to stay in the two worlds.

But for that to work, I will need to become a master in timing and self-organization. Because on top of wanting to stay with a foot on each world, I don’t work full time. And I also plan to give some conference talks this year.

We will see, I am optimistic that I will make it. I promise I’ll write a post at the end of this year with details on how I managed to achieve all that ;-)

[daianymargarita]

Why not trying a quickie?

Quickies are underestimated, in my opinion. I’ve tried them a couple of times and it was really cool. Ways better than people would think. I really enjoyed each time!

Of course I am talking about quick presentations, lightning talks. What else? :P

Without really intending to, I believe I am becoming an ignite speaker. Because I’ve managed to present 3 times in that format in the past months and I’ve discovered I like it a lot. Here are the three main reasons why:

It forces me to stay concise and say more with less: which is not a piece of cake. It’s a real challenge and of course it depends on the topic choice. Although I do believe that any topic can be well presented in 5 minutes, it is true that some are more difficult than others to compact like that. Even bigger is the challenge to put up an interesting presentation with such a time constraint. But I gladly take that challenge because it trains my ability of cutting the crap and going straight to the point.

It’s easier to rehearse until the talk is completely dominated: for the simple reason that it takes only 5 min. I’ve given 30-min talks before and I could practice only a couple of times, with lots of effort to find the moment for it. And something that gives me a lot of self-confidence when performing on stage is having practiced my speech enough so I feel totally comfortable with it. With this I don’t mean memorizing every word, of course, that’s a very wrong thing to do. I mean feeling confident that I know the speech structure well and the key points of the presentation, with the main message I want to deliver.  

When recorded, the talk is more likely to be watched when shared: because it’s easier for people to find 5 minutes time to watch, while going in the bus or underground on the way to work for example. Hence, there are higher chances to reach out to more people and maybe get some/more feedback. Which is always good!

Since I kind of enjoy getting on stage to tell people stories, I follow quite some number of tech conferences on twitter to keep an eye on speaking opportunities. On the other hand, since I discovered that I like quick presentations, I couldn’t help noticing that only a minority of events offer this format. And when a conference offers it, the number of slots is incredibly small in comparison to normal-length talks. Take a look at these two examples:

1. Devoxx Belgium

2. Devoxx Morocco

Those images were published in twitter by each conference respectively. By the time I am writing this post, the CfP for the Belgium edition was already closed, so the numbers on the image are final. But the CfP for the Morocco edition is still open for a week. In any case, it’s easy to see how underrepresented the quickies are. 

Of course not every event is suitable for quick formats, mostly due to the target audience. Personally I like a good mixture of presentation formats in a conference, because I think it makes it more interesting. I just would like that the available slots for quick formats were more. I believe it would also stimulate more speakers who never did it before to dare and try it out, which in turn would make the formats more popular and hopefully more enjoyable/demanded by the audiences.

Speakers don’t seem to like quickies much...

I suspected it before, but I definitely confirmed it when I volunteered as a reviewer for the last CfP of the DevOpsDays London. When I read their tweet asking for volunteers I decided to give it a try, so I could get a first-hand impression of the submissions of such a successful community conference, to better estimate my future chances should I decide to submit something next year (this year I couldn’t). They have a really cool and exemplary anonymising process for their proposals reviews, by the way. 

The DevOpsDays conferences have the particularity that (usually) the number of available speaking slots for 30-min talks and ignite talks are the same. This is something I haven’t seen in any other tech conference so far. And I like it!

But, for the DevOpsDays London for example there were around 120 submissions for full length talks and only around 13 for ignites. So, speakers don’t seem to like ignites much, uh?

That’s a shame, in my opinion. 

Speakers out there, why not trying a quickie? Come on, you might like it! :-)

[daianymargarita]

The story of a gift exchange: giving & asking for feedback at a community conference

A couple of weeks ago I had the honor of participating as a speaker at the second edition of the DevOpsDays in Kiel (check my impressions of the event here). 

I presented an ignite talk on why I believe that DevOps is an “Umbrella Term” for business evolution. Check it out: 

But this post is not really about my presentation (although any feedback is of course always welcome! :P), but about the experience I had giving and asking people directly for feedback.

Feedback is a gift

Of that I am deeply convinced. And it should be treated as such. It doesn’t matter if we get criticism, neutral opinions, positive but not concrete opinions, or very specific suggestions for improvement. The point is, no one is really forced to give us any feedback. It remains a very personal thing for anyone who decides to share any comment with us or not. So when someone gives us feedback in any form, it should be appreciated.

Of course it is easy to try to justify ourselves whenever there is criticism. But something I have learnt in the past years is that we shouldn’t take a defensive attitude, but rather accept the comment and later on decide what to do with it.

In my opinion, when it comes to feedback, at first we should aim for quantity over quality. The idea is to try to get as many comments as possible and then of course, filter out. This blog post describes a very interesting method to filter out and try to get the most useful feedback from all comments received. The more feedback we get, the higher the chances that we are able to fish out some “diamonds” or “spades” that we can use to improve.

Letters to Santa: asking proactively for gifts!

Having presented already a couple of times before, I had already a bit more of self-confidence. But the previous times I didn’t really get any concrete information as feedback that would help me improve for the next time. I was lucky to at least have gotten some comments either from the organizers or indirectly from the audience through a couple of tweets. In general it was positive, so I was happy. But this time I didn’t want to just sit and wait for the organizers to (maybe) say something to me, or check my twitter feed like crazy searching for any comment.

This time, after I presented and the initial adrenaline rush was gone, I decided that I would take the issue in my hands. I would just approach people and ask them directly for their impressions of my presentation. This would be my special and (hopefully) productive way of starting to network at the conference.

I approached people with a smile, and after introducing myself I would just go straight ahead and ask the following:

Did you hear my presentation?

Did you like it? 

What did you like the most?

Is there anything you think I could do better in the future?

I talked to some 20 people at least, I can't remember exactly how many. But their reactions were very interesting.

They would just smile back at me at the beginning of the conversation and answer yes to the question if they had heard my presentation. Then everyone would tell me they liked it (maybe due to social pressure of me asking so directly?) but the interesting part of their reactions was when facing the 3rd and 4th questions.

Some of them were surprised, others reacted naturally and just took a bit of time to think, some were visibly a bit uncomfortable, some even would ask me: "what is this? A direct feedback session?!" To which I would just reply in the most natural way: "Yes! And please be honest, this is the only way I can find out how I can get better, by asking the ones who heard me, so you would be doing me a favor!".

In general they would tell me comfortably what they had liked the most, but finding something I could do better was usually not that easy and comfortable. Of course there were things I could have done better, and I even got some very concrete suggestions from some of them. But what got my interest and fascination were the following two facts:

People are not used to get confronted by speakers directly like that.

People are just not used to give concrete & actionable feedback.

Let's address those two facts now one at a time.

1. Being asked directly for feedback

This is a situation that can be found in any possible context. But to keep a better focus, in this post I am going to stay concentrated in my particular one: conference attendees being confronted directly by a speaker asking for feedback.

Why is it so strange that a speaker wants to know how her presentation came across to the audience and what she can do to improve? It should be the most natural thing! But the problem is, speakers don't usually do that. No wonder the surprise of the attendees when one decides to do it.

Now, the next natural question is: why don't speakers ask for feedback? Well, hard to answer. Having been in that situation before I can say that sometimes it's just shyness (at least that was my case). But I can imagine that some other times it can be a bit of carelessness, or maybe just following the status quo: just being OK with vague other indirect sources of feedback.

This should change. Especially in community conferences where it's easier to get in touch with the audience. It would only bring benefits to everyone, not just to the speakers. Because at the end we would get better talks and an improved culture of feedback.

2. Giving concrete and actionable feedback

After hearing a presentation you can immediately know if you liked it or not. But putting into words what exactly you liked the most is not a usual thing to do (I believe), and trying to find an aspect to improve and formulating it concretely is something we even more rarely do (if at all). Why is that so?

Simple: we are not used to do that. It’s not an easy thing to do. But I am deeply convinced that it’s a skill that we can gain just by practicing whenever we have a chance. 

It doesn’t mean that we should avoid giving criticism. It’s not about giving positive or negative feedback, but about naming a concrete/specific aspect that was good or can be improved. And even better if we are able to give a suggestion on how to improve.

Here a couple of examples of the feedback I got. It shows a comparison on what I consider vague and concrete: 

“The topic was very interesting”  vs. ”It showed me a new perspective to the topic I had not considered before.”

“It was a bit too fast“ vs. “I think you could have maybe added more breaks in between, some pauses so that we as the audience have the chance to process the information“.

“I liked your enthusiasm“ vs. “I liked that you started by telling your story, because it supports your enthusiasm and your call to action to people at the end. Only passionate people can be replicators of a topic.“

I hope it’s easy to recognize the differences. The second ones are the “diamonds” we should all be looking for.

The gift exchange: talking to the other speakers

As I mentioned, giving concrete and actionable feedback is a skill that can be learned just by practicing. Since I practice what I preach, after talking to many attendees, I decided to approach as many speakers as I could and give them my feedback on their presentations.

I did it also because I felt inspired by the vibe in the conference. It was a nice way of networking and it would serve me as well as a practice. Because I always try to do my best to give my feedback as follows: honest, constructive and concrete. Including suggestions for improvement in case I could think of any.

So I honestly didn’t do it with the expectation of getting the favor back. But it was great to see how, after hearing my comments, most of them would also give me some concrete feedback. It was a gift exchange! :-)

Conclusion

We should all strive for a better feedback culture. For this, the easiest thing to do is to start by giving. The more we practice the easier it gets to give concrete and actionable feedback. And I can assure you, eventually you’ll get also your gifts when you need them. I hope my post can give you a bit of inspiration to go out and cultivate the “feedback plant”. It will blossom sooner than you think ;-)

[daianymargarita]

We are all unicorns! - My impressions of the DevOpsDays Kiel 2018

 We are all unicorns! Those were part the starting words of Sabine, the conference chair, at the beginning of day one. And I couldn’t agree more!

DevOps is definitely not reserved only for those so-called “Unicorns”, any IT organization of any industry sector, of any size can (and should!) “do DevOps”. And it’s precisely in events like this where anyone gets the chance to hear stories from others, learn and share knowledge. The DevOps movement has been around for almost 10 years already after the first DevOpsDays conference was held. Meanwhile, the community has grown a lot and there are plenty of real stories available that proof that anyone can do DevOps. That we are all unicorns.

But beyond that, I think what Sabine meant was that the simple fact that we were all gathered there, starting yet a new edition of the DevOpsDays conference was a clear indicator of our common interest for improvement, a desire to get better, to find out how to maximize our performance in this rapid changing IT world. Because we can do it! We are all unicorns! 

And with this inspiring opening, the table was served. 

But before starting with the talks, there were some opening words from the Minister-President of the state of Schleswig-Holstein and the Mayor of Kiel. I found really nice that the local politicians show their interest and support for the event because it reinforces the image of Kiel as an important IT hub in northern-Germany. It is specially relevant for the development of the local community, which I think should be one of the purposes of the organizers when bringing a conference like this to their city.

After all the opening rounds, finally the talks began. I don’t intend to go through my impressions of each of the presentations, but rather tell about my personal highlights in general.

The keynotes

The first keynote was held by Dr. Frank Hollenberg about the success factors of DevOps adoptions according to his experience. He didn’t spoke any theory, using 5 concrete stories he explained in each case the context, the problem to solve, the measurable goal to achieve, and what they did to solve it. It was his way of sharing the lessons learned with us. He didn’t use any power point (or similar) presentation, but only those 5 stories. And this is an approach that I specially liked because (in my opinion) it forced the audience to pay more attention to what he was saying. Therefore it was for me one of the highlights of day 1.

The keynote of day 2 was held by Avishai Ish-Shalom about “The missing user stories”. It was for me an “eye-opener” that things like technical refactorings or “forgotten” use-cases like supporting the change of an email, the deletion of an account, are usually not present on the team’s backlog. We tend to focus more on “business” use stories and forget that not only the end user of the system is important, but every person interacting with the system in any way is a user. So, the developers are the first users. He formulated these ideas in such a way that I can imagine many people in the audience thinking: Yes! that’s so true! we should definitely do something about it!. In my opinion it was a sharp call to action for everyone to think twice about what user stories the team needs to implement.

The closing keynote of day 2 was held by Dirk Lehmann, it touched what in my opinion is the most important factor of any DevOps initiative: Trust! The title was: “Trust as a foundation of DevOps” Unfortunately I had to miss it in order to catch my train back home. But after reading some tweets with the impressions of the audience being so amazed by the talk, I decided to google it up a bit and it turns out Dirk gave it last year as well, and here is the video:  https://vimeo.com/219025674 

DevOpsDays Kiel recorded all talks as well and they will be published, but just in case anyone missed that last keynote like me and can’t wait, the link above will do the job ;-)

For me it was really amazing! The best possible closing for the conference.

The rest of the agenda

The program was well balanced between case studies of DevOps adoption, technical talks, innovative topics (for me) like DevOps applied to teams developing AI & Machine Learning algorithms and cultural talks. I had the honor of presenting an ignite talk about why DevOps is important for any Business in order to evolve and become better. Here is a post where you can check it out, but for now let’s focus on the conference as such ;-)

As in any DevOpsDays conference, the afternoons were filled mostly with open spaces. Even though there were almost no suggestions till noon, by the time the agenda needed to be filled, the topics for discussion appeared magically and we could fill the slots. I have the impression that the groups had a nice knowledge exchange and interesting discussions. I participated as well and had a great time telling my stories and hearing also from others.

The evening event on Day 1

We had lots of fun at an irish pub with pizza and drinks listening to a local band playing some country-rock, which was truly entertaining! I had the chance to speak more with other attendees and the organizers in a more relaxed way and getting to know each other a bit more. And the music was really good in my opinion! A fantastic evening indeed!

The local community

I think the conference had around 100 people. I don’t  know exactly how many we were, but it felt like the perfect size for such an event. We weren’t too many, but also not too few. And there was a really good mixture of international speakers and local ones, which is not always the case. Especially the good representation of local speakers was for me yet another indicator that we are not too far behind as a community from other major IT-hubs in the world, which is good to know. 

I engaged in conversation with lots of people during the breaks and in the open spaces and it was a really interesting experience. It was easy to reach out to the speakers and engage in conversation with them as well. It felt for me like a kind of camp, with the spirit of collaboration and desire to learn from each other. I definitely prefer community events like this over big conferences with business dress code :-P

The catering

Last but not least I would like to make a special mention to the catering of the event. We were very well taken care of, with food, soft drinks, sweets, coffee, tea. Everything we needed. My compliments to the organizers.

In conclusion

Again, my compliment to the organizers. You did a great job putting up a very interesting program and with all the rest I already mentioned. The second edition of the DevOpsDays in Kiel was a huge success in my opinion and I can only look forward to next year’s event. You can be proud! Thanks a lot for enabling such an effective knowledge exchange and inspiring us. We are all unicorns! :-)

[daianymargarita]

FoMO at the enterprise: What we can do to stay productive

This was the topic of an ignite talk I gave last year (2017) twice: 

First at the DevOpsDays Stockholm :-)

... And later at the Ignite Kiel event. :-)

They recorded it in Kiel. If you have 5 minutes free, watch me (the talk starts at minute 2:30)

[daianymargarita]

My journey in tech so far... and the path to starting this blog!

I started my career as a software developer. In 2011 I joined Kuehne + Nagel in Hamburg as a java developer for the KN FreightNet project. This was the first agile project at all in the Global IT organization of the company, and I had the chance to be there from the beginnings. My world became “agile” and I got so interested in “the big picture” that I began helping with more analytical and communicational tasks in my team and inter-team collaboration. 

After a short break due to my maternity leave, I completely shifted from software development to requirements engineering, collaborating as well with our department’s agile coaching team in retrospectives moderation. 

It was also after my return, that I got caught in the “DevOps” movement, because I was reassigned to a team where the first continuous deployment pilot of the company was under development. It was a big learning curve, but to me it was a new, challenging and fascinating world.  

I started learning quickly new concepts, principles, practices and behaviors. I started attending as many meetUps and conferences as I could to hear the experiences from others and see what I could learn. I discovered a big community happy to share knowledge. 

That’s how I realized that I also had stories to share. Listening to others made me realize that what we were doing in our department was also a cool and interesting experience to share. So I decided to start talking around about the cool stuff we do for the KN FreightNet platform at Kuehne + Nagel.

After talking for the first time ever in a conference (Delivery of Things World Berlin 2017) telling about our journey to continuous deployments, I decided I would definitely do that more often. It was such an adrenaline rush! Apart from all the valuable insights I got from all other talks.

So I decided to add public speaking as one of my professional features, and happily I have plenty of food for thought at my working place, where I get cool ideas to talk about. And they are happy to have a passionate advocate like me promoting the cool stuff we do. It’s a win-win situation :-)

I spoke two times more on 2017, and once already last week at the DevOpsDays Kiel 2018. Who knows, maybe I’ll speak again sometime this year somewhere else :-P

But I realized that very often I have a pile of ideas in my head I would like to get rid of and somehow never find the chance. That’s how I decided to create this blog.

Let’s see how this pile of ideas grows. Stay tuned! :-)