Building A Career Toolkit

Toolkits contain many tools that allow different tasks to be performed

I have always found that taking the time and making the effort to know the people in my organizations is important to me as a leader. I have a number of stories that I will share in other stories about the many techniques that I utilized to accomplish that, but today I wanted to relay a story about a couple of college hires and our first conversations.

My telecom employer recruited and hired recent college graduates into a new hire development program. Usually, they remained in the program for a couple of years getting some generalized exposure to a number of different organizations within the company as well as more specific training in areas of interest. They took on projects and were evaluated on the results. For a couple of recruiting seasons, we did something different with several new hire employees for an organization I was building in Dallas. While they were affiliated with the new hire development program, we piloted by having them also align directly to my development organization. They had a manager on my team that provided the day-to-day work assignments while at the same time having activities also assigned by the new hire development program.

As new people joined my team, I always tried to sit down with them collectively and learn a little about them and their background. I also explained my background and communicated my “open door” policy for them to connect with them about any concerns, questions, ideas, etc. I always encouraged each of them to set up a one-on-one session with me every four or five weeks to stay connected and for me to provide some mentoring / coaching support for them. I stressed that it was their responsibility to set up the sessions and for any action items that came out of those sessions – for me or for them --- to track them and we would discuss at the next session. I stressed that these sessions were for their benefit and that they needed to take ownership for scheduling them. I did indicate that if there were long lapses between sessions, I would remind them to schedule a session soon. Organizationally, these employees were two or three levels below my level and based on input from their new hire development program peers, it was a big deal to be meeting with such a senior manager. To me, it was just doing the right thing.

The first time I met with two of my new hires, let’s call them Bob and Joe (not their real names), they had decided to meet with me two-on-one instead of one-on-one. I was ok with that. Bob and Joe had only been with the company and assigned to my team for about three weeks when we met.

Their manager on my team had assigned them a task on an important initiative we were institutionalizing, but the task was not very sexy ---- in other words, boring and real grunt work. We were trying to improve our system testing effort by automating our testing and implementing some J-unit testing that we could execute with every compile as developers submitted coded. There was a huge benefit to the organization by automating the testing and performing it with each compile. The creation of the J-units was tedious, but it gave Bob and Joe exposure to the system and hands-on experience in working their way through the code and creating the J-unit output.

Bob and Joe’s input was that the task was extremely boring and they were questioning their whole career choice based on this assignment. They were considering leaving my employer and finding another job elsewhere.

I laughed and assured them that the task was finite in length and further assignments on my team would have many other types of experiences. I explained that they were doing an important job for the team. I also explained that they needed to look at it from the perspective of adding tools into a toolkit. I indicated that I had started my career as a maintenance programmer on my first assignment. My responsibilities were primarily fixing software bugs inherited from other developers. It was not exciting, but it did give me the perspective of seeing how other developers created software. I got to see the good, the bad, and the ugly. As I began to fix bugs, I encountered some code that was so messy and unorganized (the ugly version), that I ended up re-writing portions of it to implement the fixes. Sometimes I began to make a coding change and admired the way another developer had implemented the code (the good) and made mental notes to do something similar in the future. Other times I identified and applied the necessary changes to some mediocre code (the bad, not bad per se, but it did have a bug that needed to be addressed).

I stressed that my time as a maintenance developer allowed me to develop skills that I continue to utilize in my senior executive position. It taught me how to ask appropriate questions as I solved problems and helped me occasionally guide my people on how to look at a problem differently or consider an aspect that they had not previously considered.

I explained that the J-unit assignment allowed them to see the good, the bad, and the ugly code on my business digital platform software. I encouraged them to get their manager to help them get invites to peer level code reviews for the same reason. The peer level reviews also would give them exposure to the good, bad, and ugly. In the reviews, their peers would be providing other peers feedback on the code that peer they had created / updated.

Most of all, I stressed that this initial task was just one tool going into their career toolkit. There would be many others. They would look back on this experience much differently a few weeks out. Three weeks is not a long enough runway to decide on what they wanted to do or not do.

Bob and Joe took my advice. When I met with them about four weeks later, their perspective had changed. They had gotten involved in peer reviews and other more meaningful tasks. They understood and appreciated that they were building a career toolkit and their initial assignment was just one of the tools going in that toolkit that would benefit them later.

We all sometimes must do menial task level things that are not our preference. However, they need to be done. What we get out of those tasks depends on our attitudes as we approach them. We need to look at them as developing or practicing skills that may be valuable later or even tasks that allow you to be more empathetic towards people that perform those tasks regularly.

Another key point that we need to remind ourselves or other junior members on our teams  is that nothing lasts forever.  Careers are journeys that last a lifetime ---- with the same or different employers, but lifetime journeys, nonetheless. Every task can be perceived as adding or enhancing a tool in our toolkit that will help us in whatever comes later in our career.

Bob and Joe remained on my team for a long time. Both benefited from the learnings and skills they made on my team and put in their career toolkit. They each flourished. One is still with my employer. The other one eventually left my employer but moved onto a new position at a start up company where the skills he learned were part of his career toolkit and benefitting him along in his career journey.