Career

Common interview mistakes I encounter

Comments Off on Common interview mistakes I encounter read

As a hiring manager, I have interviewed hundreds of candidates so far. The more I talk to candidates, the more I start realizing, some of the mistakes are common between candidates and I wanted to share them with you, hoping it helps you to prepare better for your next challenge.

Before I move into the list, I’d like you to remember: hiring managers do not interview people to find what they do not know! Hiring managers do the interviewing to find out what you DO know and how’s that going to fit to the needs of the team and the company. Therefore, if your actions and answers start from this point of view, you’ll have a greater chance to move ahead in your interviewing process.

Here are the 5 most common mistakes I encounter:

#1 Not being punctual

Punctuality is a highly desired characteristic in professional life. Being late to the interview already will be setting you on the wrong foot. If nothing, it will create a bad initial impression. If you see that you are not going to make it on time, try to inform the company proactively for how late you will be or ask for another slot. People will understand when you reach out, but simply being late will play against you, even if you are a very good match.

#2 Not elaborating on your experience

When the hiring manager asks you to talk about your experience, this is your chance to shine. It is your opportunity to show how well you and your skills fit into the organization and the position itself. It is your convincing pitch to show why you are the right fit for what the team needs

Do not cut it short. Do not overlook your experience, but also do not get into unnecessary details. But then, how do you answer this correctly? Do analyze the job description, try to understand the expectations from the role and what the company does. Then try to create mental connections on how does your knowledge and previous experiences benefit the company and how can you use that to contribute further in this role.

The hiring manager is not asking you to read what is visible in your CV, they are asking you to provide further details, details that are not visible in your CV, but would show that you are the right fit.

#3 Not knowing enough about the company

One of the typical interview questions is, “Why do you want to join us?”. Pay attention on how you answer this question as it often defines the fate of the interview process. Before the interview, take your time to analyze the company, what do they do? Try to find out what are their culture and core values, try to find what their mission is. If possible, also analyze the market and how do they stand. Then see, how does this fit to your own values and cultural values you live by.

Your answer must be original, as this shows how genuinely you are interested in the company. Probably, you don’t want to look like just another candidate looking for just another job.

And, if you see that what you found out about the company doesn’t interest you or does not align with your values, then better move to another company, as probably this is not going to be your next place where you thrive.

#4 Not having questions of your own

This may feel related to the mistake #2, thought this is not only about your knowledge about the company, but also about showing interest about the position, the job, the team and the challenge. The hiring manager will try to understand, what is important for you. What kind of questions you ask, what kind of values you are looking for.

Often, not your answers to the interviewer questions, but your questions will tell you apart from your competition and if you are a good cultural fit for the organization.

#5 Answering questions superficially

In a time slot of 30 or 45 minutes, it is very difficult for the interviewer to check all your knowledge, though depending on how you answer the questions it will give an indication of how well you know the topic. Answering questions with a shallow answer will often leave the impression that your knowledge is superficial or that you have not actually had that experience you are mentioning in your CV.

When you believe that a detailed answer will take too long, try offering the interviewer a summarized answer and asking them if you want to elaborate it further. If this experience/knowledge is important for them, they will follow up with more detailed questions.

Summary

Preparing for the interview with the right focus and perspective will already jump you ahead of competition. Do these to prepare:

  • Research about the company, the business and the market
  • Understand the role, the responsibilities and expectations
  • Think about how your skills and experiences can be of the benefit in this role

I hope it helps you have success in your next interview. If you found this advice helpful, please share so more people will benefit from it. Thanks!

Software practices

Moving from Scrum to Kanban

Comments Off on Moving from Scrum to Kanban read

In most of my 15 years in Software Development, I’ve mainly been part of development teams which were practicing Scrum methodology. Although we have always aimed to do it right, somehow the organizational culture and operations methodology influences how Scrum was implemented in these teams. Recently, in my current team we decided to actually move from Scrum to Kanban. Here is how it turned out for us.

Why did we decided to switch?

I am very passionate about Software Development process. Without working process I believe it is not possible for a team to reach their output potential. Yet, I am not religious about methodology used. While one methodology in one environment may thrive, it may kill the productivity in one another. So, why did we decided to switch? Was Scrum not good enough for us?

Well, I would not say Scrum is not good. I’d rather say, in our organizational environment, it did not seem the most optimal methodology. There were certain details around Scrum that we were struggling to implement properly. While I believe that it’s OK if we id not implement it 100%, I also believe that if we are missing some core things, than something is not right.

What were we actually missing? Sprint goals! We were rarely actually meeting our Sprint goals and our burn down chart was rarely meeting the lower end. Why was this happening? Were we a lazy or a dysfunctional team? Actually completely the opposite. The team was and is very focused and very productive. It was just the environment that was not enabling us to achieve those goals.

In our department we embrace a DevOps culture. We don’t only develop solutions, we also run and maintain them. Also, in addition to modern cloud based solutions we have developed, we also have to support a legacy application which is old and with a lot of hidden details. Any time we were touching the legacy application, our estimation of tasks was completely deviating because of unknown surprises.

With all these constraints, it was often that while in the middle of the sprint, we had to change priorities because we needed to fix something in the legacy app or because we needed to attend to a customer incident. In such circumstances, we could not just tell our customers “wait until the next sprint because the current one is full”. Of course our customer centricity pushed us to react immediately and solve the problem of our customer, but often issues of this nature lead us missing the Sprint goals.

Another thing that was not working for us is estimations. Estimating software is difficult. Especially in Agile environments where you have to judge the “half specified” request and give a number. But then when you give the number, you have to live with the pressure to deliver on time. Plus, often we go ahead and plan for more than one Sprint because the backlog is always larger than one can deliver, and then you realize delays in one Sprint affect the others, but on the other side the business people expect the potential date you had given them. This was another major sign for us that Scrum is not the best methodology for our circumstances.

The transition to Kanban

We did the transition in small steps. First thing first, we had a joined workshop with the team and agreed on this transition and the steps. We also pictured how the new process will look like and how do we map existing process steps to the new one.

Of course, implementing Kanban by the book was difficult again for the same reasons. One has to adapt to the organizational requirements as well. We could for example transition to continuous deployment immediately. Technically we had all the mechanisms in place. Yet, we had to satisfy some organizational expectations. Our solution is used by customers around the world. Our account managers expect us to communicate the change to them so they can communicate to their corporate customers. We also get often their help in testing major changes, so just rolling updates without a schedule was not going to work well in our case.

What we decided was to apply Kanban and release to development and quality environments as continuously, but keep production releases on a regular schedule. So far, this is working quite well.

Initial Chaos

The first day or two when we transitioned the workflows things did not go perfect. We had some Jira ticket statuses mapped not exactly as we wanted, therefore our board got messed up. Fortunately, we were able to fix this in a day and things started to get back to normal. Also, during the first week, it happened that people were confused about the flow of the process but everyone got used to it quite fast

The joy of on-demand prioritization

One of the main benefits of Kanban is that we can re-prioritize the priority backlog as often as we need. Is there a new business requirement, a burning customer incident, or a support request, we can adjust the priority on demand without feeling the stress of missing sprint objectives. This has released especially the “friction” between the Product Manger (facing pressure from the customers) and the development lead (trying to maintain the sprint promise).

Feedback from the developers

Whenever I have to drive such a change, I like to constantly get the feedback of the team mates and adjust/pivot in necessary. So far, I’ve mainly received positive feedback from the team about Kanban.

Developers feel less under pressure when they do not see a waiting list of tickets for the sprint. While we have the same level of productivity, it now feels more like a flow rather than a milestone based sprint.

This change has also substituted ceremony meetings (prioritization, tech planning, retro and review) with on-demand fully focused meetings. This has created more productivity time for the team.

Conclusion

Again, going back to my initial statement, it’s not that Scrum is bad per se. It just was not the best methodology for our circumstances. Moving to Kanban was an opportunity for us to improve our process to something that fits our needs better. So far, it has been a very rewarding experience and we enjoy it. Of course, after some time we’ll have to revisit this as well and see if we need to move ahead to something else. Continuous improvement is what we enjoy!

Leadership

Measuring the temperature of the team

0 Comment read

We are at the time that software development is such a crucial part of the business that almost everyone is lost on the river of “feature delivery” in such a way that we even forget that we have to stop and pay attention how our teams are functioning and how is our team dynamics.

The feature requests are way more in number than we technically can achieve to address. Our user base is getting smarter and smarter every day as well as they get more tech savvy, so they know more and more what they want. This makes addressing their requests a daily challenge, but this is only one side of the story 😉

When developing software, one side of the story comes from the users and key account users, but the other side comes from the business management and the leadership. Quite often, the perspective of these two groups may not end up to be the same, leading to stressful situations.

One of my favorite “soft tools” for leading teams is having regular 1 on 1s. Even though sometimes they feel unnecessary and too obvious, I religiously follow the cycle and never miss them. But why?

The reason is, for me these 1 on 1s are just like thermometers for fever. They tell me how my teammates feel, as well as answer the questions like is anything bothering them, is there anything that can be improved? These kind of questions may sound very basic and too simple, but they are amazing to identify the small-to-grow problems at their infancy phase and address them before they grow to the scale that pushes employees to leave the company.

I’m in the IT industry for ~15 years now, and if I can name one universal rule that I could identify between all the people groups I have been working together with, it’s that people don’t tell that they will leave. They just get fed up and start looking for another opportunity before they start giving you open feedback that something is going WRONG. So, what can we as leaders/managers do to prevent the situation to come to this point. In my opinion, we should on a regular basis measure the “temperature” of the team. How is the team dynamics? How do the individuals feel? Has the performance had any variations recently? These are the questions that we need to ask ourselves regularly and be wary in any of the changes, as any change to the answers to these questions is an alarm in itself that we should address as soon as possible before it is too late.

The other VERY VERY IMPORTANT topic to discuss in these meetings is, what do the team mates want to learn and further advance their skills! Continuous learning is extremely important for performing teams and the leader has to make sure they understands who wants to learn what, so one can match the daily business priorities to the interests of the team members, so they can grow personally and professionally while solving the most crucial business challenges. We must create WIN/WIN situations for our colleagues so everyone feels happy and benefits from the daily work we do!

As the saying goes, “people leave managers and not jobs”, it is our ultimate responsibility to realize if a team member is unhappy and going to leave before they make their unhappiness official, because when they do, it’s already too late!

Leadership Self development

Supporting the professional growth of the team

Comments Off on Supporting the professional growth of the team read

As an Engineering Manager I take the personal and professional growth of my direct reports very seriously. It is one of my core duties to make sure that, in my capacity, I have enabled them to learn continuously and advance their professional and soft skills. In this blog post I will share with you my formula how I support the professional growth of the team.

Understand who wants what

Every person is unique. Just admitting that defines the level of attention required to individualize the learning and growth experience. What exactly do I mean by that? Let us suppose you have a team member who is very much into data solutions. But, in their daily job, you constantly assign them frontend tasks. Maybe they will do the job, but I’m sure they will not operate at their optimal level if they don’t like frontend development.

With every one of my team members I do regular monthly (sometimes more often) 1:1 meetings. These meetings usually are for me to listen and them to talk. They are for me to understand what excites them, what bothers them, what makes them tick. I take notes and with every meeting I review my notes to check for deviations or changes. I also use these meetings to understand what interests them to understand them better personally and their professional interests.

Understanding the industry and market trends

I think it is of utmost importance for an Engineering Manager to be well acquainted with the trends in the industry and the market. In our vibrant industry, it is at the same time very difficult for us to be able to catch everything what is happening around us. Everyday we have a new framework coming up, a new cloud service, a new programming language update, and keeping up is a real challenge, so we do need to be able to filter critically the information that will be important for our future.

What has worked for me so far is to organise and classify information digestion. I use Twitter and LinkeIn to follow people behind the technologies of interest. I also follow the companies and communities behind the technologies that are in my and my teams area of interest.

This way I can keep myself up to date with what is in trend, what is being pushed and developed from big companies, therefore worth to invest time in.

Finding synergies with our company projects

Of course just knowing what are the trends and what the team members want to learn does not lead us anywhere. We have to match these two to create growth. So, how can we make these two ends meet?

We are lucky that the part of business we work in is very vibrant. We have more projects and backlog that we can manage to complete. In this backlog I constantly look to find opportunities where we can solve our business problems with innovative cutting edge solutions. I try to create opportunities where our important business goals are achieved by team mates implementing solutions with the latest technologies they enjoy. This way, a growth opportunity for the developers is created as well as our company benefits from innovative and up to date technical solutions. Win-win situation 🙂

Enabling the team to jump on these opportunities

Of course, when adopting a new technology, being a new version of a language, of a framework, or a new tool, this would mean that the team has to spend time learning it. Therefore, I as a manager have to critically evaluate these opportunities to see if this makes sense. If that new thing we want to adopt help us move faster, safer or further in our work. It should make sense from the business perspective and it should make sense from the professional growth perspective as well. When these two ends meet, I seize these opportunities.

Conclusion

As managers we should help our colleagues to be very attractive for the market, but also should create an environment that the employees would not like to leave.

As employees, we always have to think from the perspective that we are hired to solve the business problems and bring value to the company. But also we have to keep in mind that without continuous learning and improvement our value bringing capabilities diminish by time.

As the famous quote goes:

CFO asks CEO: “What happens if we invest in developing our people and then they leave us?” CEO: “ What happens if we don’t, and they stay?”

Cloud Self development

Are Azure Certifications Valuable?

Comments Off on Are Azure Certifications Valuable? read

It has been years since I stopped taking certification exams and lately I decided to get back to that adventure. In September 2020 I passed exams to be recognised as Microsoft Certified Azure Solutions Architect Expert.

Arian Celina - Certified Azure Solutions Architect Expert

Before and after passing the exam, I asked myself the question which I have seen many people ask as well; Are Azure Certifications valuable? I believe the question is applicable not only for Azure Certifications, but in general for any industry certification. Are they valued by the community and employers? Do they make a difference in your career? I have also written about this topic in the past, and yet it seems the same questions are still coming up. Let me share my updated opinion with you.

From the motivational perspective, it is very important to clarify the answer to those questions so we know why we are putting all that effort to learn and prepare for the exams. I also think these questions should be rephrased with a reversed perspective. Before we modify question, let us first discuss about the value itself.

What is the value and who defines it? Who can tell if a certification is valuable? I think think there is no single source of truth for that. From experience, I have encountered employers and peers who value a certified professional more than someone who is not certified. I have also seen opposite. As someone who have interviewed more than 100 candidates so far, I can say both can be right and wrong.

I have met certified candidates who have not been able to defend their title with knowledge. So I have met people who were not certified on a topic but were more knowledgeable than their certified peers. I have also met certified people who were subject matter experts and knew their topic in detail, kind of detail that we do not easily learn by randomly playing with the technology.

When I reflect on my late Azure certification journey but also on my previous certifications for .NET and Java, what I remember is that while preparing for the exams I have often learned hidden details about the topics which I have not encountered during the daily work. Those hidden details then later have quite often have saved me time or effort and enabled me to bring better solutions into life. This in itself is a value for me.

Considering this, the revised question I think we need to ask ourselves would be:

What do we gain from this certification?


In my opinion, we should not get certified so other people value us more because we hold that title. We should do certifications to learn better the technology we like. Of course one can do that without taking the exams and without getting certified. It’s just that taking the exams pushes you to follow a certain curricula which is reviewed by experts and that often gives more structure to the learning.

I have been using Azure for years and have quite some experience deploying and running web applications on various forms of workloads, containerised and non-containerised. Yet, when I took the late exams for Azure Cloud Solutions Architect Expert certification, I learned a lot about some not so familiar topics to me, like migrations of Virtual Machines from on-premise datacenter to Azure, about backing up Virtual Machines, or about Express Routes. Taking those exams pushed me to learn more about those topics which probably I would not in my daily work.

As a conclusion, in my opinion industry certifications are valuable as they push us to get better at that topic and this inherently will make us a more valuable contributor to our team, company and community. When we do that, whether the certification is valued by our potential future employers plays a smaller role in answering this question.

DevOps Infrastructure

Kubernetes basic questions answered

Comments Off on Kubernetes basic questions answered read

when getting started with Kubernetes, it can be a daunting task at first to get a grasp of the basic concepts which will allow you to move forward with it. I would like to try to answer some basic questions about Kubernetes, some of which I was having in my mind when I first started to learn and work with Kubernetes.

If you do not have any understanding of containers and containerised applications, it becomes even harder to realise where in the big picture does Kubernetes fit.

Explaining what containers are is out of the scope of this article. If you feel like you still need clarity in understanding what containers are and how do they help, I suggest to find that out first before moving forward. If you feel comfortable with containers, then off we go.

What is Kubernetes?

Kubernetes is a container orchestrator. And what would that be? Well, when we containerise an application, we package the application and its environment in an image, but we still need somehow to run it. We can execute a docker run command and run a docker container, but then when we have an update or a new image, we would manually need to kill the running container and run the new one. And what happens when the container crashes because of e.g. unhealthy state? Who would take care of restarting the container? This is where Kubernetes fits into the big picture.

Kubernetes orchestrates the lifecycle of a container. It can deploy containers together with their dependencies, restart them if they crash, update them if the image version changes, create new instances of the image without downtime, etc. Most of these can be fairly easily automated with the help of Kubernetes.

What is a Pod?

Well, in the previous paragraph I made a false statement. Kubernetes doesn’t actually focus a lot directly on the containers. Kubernetes works on a one level higher abstraction concept called Pods. Pods can be thought of as mini virtual machines which can run multiple containers inside. Usually, Docker is used as a container engine, but this can be configured differently if needed.

Ideally, a pod would run a main container (e.g. one application or a service), and it can run other side containers which would serve the main container. The reason behind this is that, if one of the containers signals to be unhealthy, Kubernetes will kill the whole Pod and try to create a new one. Therefore, it’s a good practice to have one main service running in a Pod, and if that service is not healthy, then the Pod is instatiated by the orchestration scheduler.

What applications can I run on Kubernetes?

Anything that can be containerised. Kubernetes supports stateless as well as stateful applications. Although, from experience I can say, running stateless applications is easier. That’s because managing the state requires more management work from our side.

Personally, I try to push stateful software outside Kubernetes and use them from PaaS providers. One example of such a scenario is the Database. This leaves me more room to focus on running the in-house developed applications and less attention on dependencies.

What is kubectl?

Kubectl is a CLI tool to query and manage kubernetes. Kubernetes has several types of resources. Those resources can be Pods, Services, Deployments, ConfigMaps, etc. Kubectl allows us easily to find information about those resource as well as change them. One example would be to read the deployment configuration of a pod, another would be scaling up a deployment.

One can get most (if not all) of these using a UI, but come on, who needs a UI nowadays ☺️.

I want to have a Kubernetes cluster, what are my options?

Starting from the most obvious option, you can get some bare metal servers and install your own Kubernetes cluster. Though, I would strongly not recommend this until you really know what you are doing. Kubernetes is a very complex system. It has several components and a good configuration would require several servers. Only keeping a safe, available and up to date configuration would be a challenge, let alone taking care of more complex topics like the security of the cluster.

Unless you are constrained here, I would strongly recommend you start with one of the cloud providers that provide Kubernetes as a service. It is offered by many providers, amongst them Azure, AWS, and DigitalOcean.

The cloud providers abstract away the management of the cluster itself and give you freedom to focus on actually building your application infrastructure.

When is Kubernetes good for me?

If you have only one or two applications running, you are better off without it. Kubernetes offers great functionality to orchestrate containers, but it also comes with an administration overhead. If you are not building many (3+) different applications or micro services that you deploy frequently (several times per month), in my opinion it would not be a good option.

Kubernetes is a great helper in an environment of multiple micro services where continuous delivery is the process. It is an overkill to run 2-3 applications which get deployed a couple of times per month. You get my point.

Start small and adjust as you grow!

Conclusion

Kubernetes is one of our time’s coolest tools. It has enabled many business solutions scale flexibly and shine. But at the same time, it can be a complex beast. Take it with a grain of salt and prepare well before adopting. Equipped with knowledge, it will take your DevOps processes and with it your possibility to reacting to changes to a whole new level.

Programming Self development

My language learning framework

2 Comments read

The most important lesson that I have learned in my career of almost 15 years in software development is that programming languages are just tools to solve real life or business problems. About 5 years ago I was doing full time .NET, then I jumped to Java for about two years, then I switched to Ruby and Rails, and just recently I started using Kotlin to create two microservices (don’t ask me why, the business needed it ;)).

Because of this, there is no point whatsoever to be bound to a language/platform religiously. The languages are tools but it’s the core knowledge of computer science and software development practices that prevail.

These changes have been inspired by different rationales, sometimes influenced by the employer and sometimes by the economic conditions of the runtime environment. E.g. hosting a Java web application during 2006 was way more expensive than a PHP application, therefore, I used PHP as a primary language for my web facing pet projects. So during my career so far, I have used Java, .NET, PHP and Ruby as my core languages and also have implemented small solutions using Kotlin, Javascript, and Python.

To adapt to this changing environment of ours I have noticed I had created a framework, which I call my language learning framework. The framework itself is not about the language per se, but about the whole ecosystem around that language. It came as a result of identifying unchanging things around any language ecosystem. E.g. no matter the type of language, there is a way to deal with strings, numbers or arrays. Or the language has some sort of collections.

With almost every language that I have used, I have had the need to also learn a framework to develop web applications, a framework to do testing, and other common things around the application. So out of this experience, here I share with you my language learning framework. It lists the things I try to learn or pay attention to when I start learning a new language.

I. Language
1. Runtime & ecosystem (general knowledge)
2. Syntax
3. Data types (if there are types)
4. Main constructs
4.1. packages/modules, classes and methods/functions
4.2. loops & conditioning
4.3. arrays
5. Core libraries
5.1. String manipulations
5.2. collections (lists, arrays, maps, sets)
5.3. math (rounding, sqrt, pow, PI)
5.4. important packages/gems/etc. and any language/platform specific library
II. Frameworks
1. Application development (evaluate popular ones and pick one)
2. Testing (unit & integration)
3. Main design patterns and in that language
III. Toolset & Other
1. IDE platform specifics
2. CI/CD
3. Deployment (does the docker & Kubernetes work or is there anything platform specific)
4. Community
5. important learning resources

Some of these items on the list are dead clear so you just follow it, but some of them are hard, like choosing which framework to use. How do you choose which framework to pick. Well, in those cases, I use different inputs to make my decision but most often it is an educated guess. What I consider is, I ask my colleagues/friends if they have experience with any of the ones I am considering and get their opinions. I also evaluate possible blog posts about them and also try to measure the popularity by checking the number of contributors, how often does a major version gets released, how many job openings I find requiring that framework, and based on all these inputs I narrow my list to two options. Then I try both of them with a certain simple scenario and I try to evaluate how easily I could implement that scenario and get a feeling of both and then decide. Out of all the factors I consider, how much I like it and how many job vacancies are there requiring that framework are two criteria that weigh most with me. The pleasure to work with is very important for me, but also having an opportunity to use it (have an employer/business which actually uses the framework) is also important in my opinion.

One important thing is, when I try to jump on a new language, I try to do all these steps in a relatively short period, potentially with max 2-3 months, and then try to repeat it at least 2 times with 2-3 sample projects. In this way I make it possible for my brain to remember it, otherwise, if it takes too long to go through the list, I forget things in between and the end result is not satisfactory.

This is not a definitive list and doesn’t include everything we need to learn to be productive in one language/platform, but it certainly serves as a good starting point for me when I want to jump into a new language.

Do you have a different approach? Share with us!

Leadership

Taking over a team, what should you do?

0 Comment read

As team leaders, chances of us taking over a team rather than creating a new one are higher. When taking over a new team, I have found very useful to go through several steps to find out some information before moving forward.

As a baseline, I first want to state what is important for me at this stage, so the next steps make more sense to you. I believe that some characteristics must be present in a team to make teamwork possible, and one of the most crucial one for me is communication. If there is no open and clear communication, then you are opening the doors to all sorts of problems, starting with misunderstandings to not delivering any work. So let’s go through my observation points:

Communication

This is the most important one for me and the key to all the successes or failures in the team. It is of vital importance to understand and define the communication means the team feels most comfortable with. Some do prefer verbal communication (this is also my preference when the team is on site) and some do like more written communication, especially when part of the team is remote. From experience, a mix of both, a hybrid communication works pretty well. It maintains the human touch as well as leaves chance for missing or remote people to stay informed as well.

Team dynamics

I believe every team has an individual spirit. That is not individuals, but the group acting together. It is like a one way hash of the team. It is like that as if you remove one person from the team, or if you ad one, the team spirit is different, so the hash changes. The team dynamics tell you how well the currents in the team flow. How well do the team members communicate and get along with their teammates? Who dominates, who leads, and who is the strong influencer? Who is more silent and needs help to get heard and who maintains the balance of the team? Finding answers to these questions will help you determine where and how should your focus be directed to try to get the team to an optimal performance level,

Individuals in the team

Although the team spirit is super important, individuals in the team are as important as the former. Every team member has their unique personality, therefore, their influence on the team is individually different. Ignoring one team member may result in breaking the whole team dynamics. One needs to continuously foster and maintain the individual relationship with every team member. One thing that helps this a lot is having 1 on 1 meetings regularly to check how they feel about the team, is there anything that can be improved or changed that can contribute to having a better engagement or more interesting experience.

Strengths and weaknesses of team members

To take the team to an optimal performance level, I find it of utmost importance to fine-tune or calibrate the way individuals contribute to the team. Every individual has strengths and weaknesses. The importance is to engage them on things they are best at while allowing their teammates to cover on their weaknesses. This contributes to people feel better as they perform best when they do the things they feel most strong at. One might argue that we should push our teammates to improve on their weaknesses, and yes, I agree, but remember, the focus of this post is on improving team performance, there will be another post on helping individuals thrive 😉

Conclusion

When you take over a team which is already established, it is not an easy task to find out how to behave best so you improve the team performance and do not decrease it. My usual approach in these cases is to take my time, usually for a sprint, and do nothing except observe these characteristics. After I create the picture in my head, then I start approaching individuals to find out more about them and complete the picture. It is this time when I create a list of things that need to improve and start acting on improving what needs to be improved and reach a fluent delivery cycle.

Do you have a different experience or opinion? I’d like to hear about it. Please share it with us.

Leadership Self development Software practices

How to unleash employee creativity

0 Comment read
How to unleash employee creativity

At my current company, Springer Nature, we have a great benefit of having the freedom to dedicate 10 percent of our work time working for a side project, learn something new, or on anything that can help us learn something new. Our employer gave us this freedom so we can grow personally and professionally, but one observation I have had during these months that we are practicing this was that it also helps to unleash employee creativity.

How we do it?

This initiative firstly started as a Hack Day for developers. Then we renamed it to “10 percent time” so it can be more inclusive to other profiles that are part of our department, such as UI & UX designers, PMs, and POs. We spend every second Friday of the month by doing something other than work related stuff, something that would in one way or another help us learn something new. Sometimes we do an online course, test that new version of a library we use every day, evaluate a new framework or even learn a new programming language. Beginning of the day we do a joint stand up where we share our plans for that day with other participants. Sometimes someone likes somebody’s idea and we join forces for that day to create something awesome. By the end of the day, we gather together and share what we have created and what did we learn. Some do a demo, some showcase their code and some just summarize their learnings. During this sharing session often people get the inspiration for their next hack day, or sometimes we realize that a presented idea could be of a benefit for the company to grow as a project and we pitch it to our colleagues and management.

What did we do during these days?

During the previous Hack Day, one of my colleagues did create a simple  NodeJS CRUD API as she wanted to learn NodeJS. On the other side, as I usually do backend stuff, from time to time I am quite interested to learn things about frontend. For a long time, I wanted to learn Vue.js, so I volunteered to create the frontend for that API. During those few hours of coding, we managed to do a simple Vue.js application and implement a frontend for CRUD operations of that API. The code can be found at https://github.com/acelina/books-fe GitHub repo. Of course, I didn’t become proficient in Vue.js in one day, but next time I need a frontend for my app, at least I know where to start and I value this.

In another case, me and a colleague of mine started a Hack Day project to improve the process of managing code challenges for our developer candidates. We worked on this project for  three Hack Days. The result was an application that included features like managing the automatic creation of a GitHub repo for a candidate, including there her code challenge and give her the privileges to commit to that repo. It also included the feature to manage the workflow of submission, so when the candidate creates a PR of her finished code challenge, the application will remove her from project collaborators and notifies us in a Slack channel that a submission is ready to be reviewed. It was a three fun Hack Days for two of us and it resulted in a production-ready application which eliminated manual labor. There are several other successful results which came out of this 10 percent time.

What we achieved?

I understand that the projects we do during these days are never ready for production, but we achieved to create a culture of sharing the knowledge with others and by it to foster employee creativity. This 10 percent time creates space for us to experiments with things we don’t have the time to experiment during our regular work days because of deadlines or priorities. It also helps us to grow professionally and personally. Sometimes it results in a useful thing for the company as well, and most importantly it helps us to unleash our creativity while having fun. As a developer, I value this a lot in a company, and I would recommend every company to start practicing it. You never know where brilliant ideas come from!