From the Bench to the Playing Field
From the Bench to the Playing Field
A recommendation for how to utilize the engineers that are on "the bench".
Join the DZone community and get the full member experience.Join For Free
photo credit: unsplash.com
Most engineers, fresh out of college, are starry-eyed and can’t wait to change the world for the better. They go through the grind of learning, semester exams, project work, etc; to land their dream job at a reputable IT/IT services company through campus placement. Sometimes; however, these aspiring software engineers are placed on the bench. This also occurs with even experienced software engineers.
Most of the time, the conversations about the IT services industry are limited to the project size, client reputation, client turnover, etc. No one seems to ask the tough questions about the challenges, be it technical, people, or process-based, being faced by engineers in the IT services industry.
I have noticed this issue of disenchantment with engineers when I conduct interviews. A couple of common reasons that I keep hearing from candidates include: ‘the project is about to be completed’ or ‘the project has reached the support/maintenance phase’.
Why do software engineers seek new openings or projects, if the tag (project name) is about to be disassociated from an engineer? Is the usefulness of an engineer limited to the longevity of a project? What discourages an engineer to quit? I have given my two pence on these ideas, based on my personal experience and observations.
The term ‘Bench’ is not unfamiliar, however, here is an analogy for better understanding. In football, only 11 players are allowed on the pitch, but three players are considered as substitutes, ready to replace a player on the pitch, in case of injuries. These players usually sit on a ‘bench’ and hence the term. Similarly, IT companies hire some resources who can be utilized when in need. So, the bench refers to the percentage of a company’s employees that aren’t working on any project for the time-being but receive regular remuneration.
When companies anticipate projects coming their way, they would rather have their clients believe that they have the necessary resources available immediately; hence, they start hiring for the bench.
On the flip side, high bench strength could indicate that resources are not properly utilized. This does not mean the company is not responsible for the professional development and growth of its engineers.
The fear of layoffs and not being assigned to a project can definitely drive engineers to look for better opportunities elsewhere. To mitigate such occurrences, companies are now actively doing a couple of things — improving utilization rates and reducing bench strength.
Let’s dig deeper into this conundrum by identifying additional data points.
Projections — the What
We all build products/projects, maintain, support, etc; but, as software engineers, we need to showcase our abilities to the outside world. One important method is to create a portfolio of our work. Other methods include:
- Conducting knowledge sharing sessions
- Conducting Workshops & Meetups
- Building an MVP of an idea and selling the same
- Acquiring certifications
Some engineers are already aware of the above-mentioned methods and some of us have learned the hard way. When a team of like-minded engineers on the bench focuses their efforts and skills through one of the above-mentioned channels, it can:
- Motivate the team
- Upgrade their technical skills
- Improve their problem-solving capabilities
- Refine their persuasive presentation standards
- Provide exposure to other parts of the organization
Whether an engineer is on the bench or associated with a project, it is important for them to learn and be exposed to different technologies and methodologies. This is what will truly make a difference in their careers.
Case Study — the Why and How
One of my responsibilities is to engage the Java bench in my organization. Here, we do not term them as the bench, rather as the ‘Talent Pool’ (Java Talent Pool). When you feel responsible for a group of people in your organization, it also means that you are responsible for their profiles. I have been given opportunities to experiment with some of the techniques described earlier.
Conducting Knowledge Sharing Sessions
The expectations in the services industry are drastically increasing. Engineers are expected to clearly communicate the anatomy of any topics they are familiar with. Being in projects provides experience on specific tools and frameworks, varying from novice to basic understanding. Discarding the knowledge gained in one project, after moving to another project, may not provide a comprehensive picture of what has been learned. So, knowledge sharing by conducting regular technical sessions across teams or like-minded engineers is beneficial to both.
- The presenter deep dives into the concepts, so that they can be delivered with clarity.
- The presenter is prepared for external presentations as well.
- The audience gain familiarity with the tools and frameworks presented in the session, which prepares them for the next set of assignments (could-be projects).
Recently, we conducted workshops on Google Cloud Platform (GCP). AWS, the longest-standing cloud provider, is maintaining its lead-in and holding the lion’s share of the market. Some organizations, like Spotify, have moved towards GCP. With millions of songs and billions of playlists to support, Spotify moved its infrastructure to Google Cloud over two larger rivals, Amazon Web Services, and Microsoft Azure.
A small team in our organization was given the responsibility to evaluate GCP for a client. The learning experience was tremendous and we conducted GCP onboarding sessions and workshops for the rest of our employees. We were able to substantially shorten the learning curve for the rest of the employees.
Conducting workshops needs more time and effort, compared to knowledge-sharing sessions. Sessions usually take place between one and two hours, whereas workshops take more than three hours and require some infrastructure, but workshops reach the targeted audience more easily.
‘I think I have a great idea!’ is how most product stories begin. The implementation and success of the product remain a daunting and risky proposition for most engineers. The most effective way to minimize the risk involved in bringing a new product to market is to create a Minimum Viable Product (MVP). This is also a great opportunity for engineers to work on original ideas and understand how products can be nurtured and brought to market.
My current employer encourages new ideas and motivates its employees to bring these ideas to life through an internal event called Infinity. These ideas are incubated, scaled, and made market-ready. Our engineers in the talent pool have made an immense contribution to the creation and incubation of new ideas.
I have mentioned a couple of pointers where an engineer can contribute to the organization, without being associated with a project. This culture reinforces that it does not matter whether an engineer is tagged with a project or not; what really matters is whether the individuals can learn, work as a team, and deliver value/projection to the organization’s growth.
Published at DZone with permission of Kayal Vizhi . See the original article here.
Opinions expressed by DZone contributors are their own.