One of the goals that I have set for myself over the past several years was to start to train engineers in a semiformal manner. This goal would accomplish a few things:
Long term team viability
- Not everyone will want to stay on the same project long term
- Not everyone will want to stay on the same project long term
- There may come a time when someone should be moved off of a project for growth reasons
- Bus Factor
Learning Opportunities
- There are some fantastic senior engineers on my projects who have a lot to share
- My projects are large enough that we can train others without affecting the resulting product
- A semiformal program puts some boundaries and objectives in place
Ability to fail safely
- By providing a support system we can allow failure in the small and not affect our clients view of our progress
- We can grant authority to trainees so that the experience and learning is “real”
Tech Lead Program
I chose to start with the training of tech leads. On any team that we have, the tech lead position is one of the hardest to fill. I wanted to have a pool of tech leads, who were already vetted, to pull from should the project flex in size or shape.
For the tech lead program, I examined my own experiences at SEP to come up with the following concept statement: “We have not trained our tech leads in the best way in the past, let us fix that.” It is simple, and vague, but it was true for me and, as it turns out, it has been true for others in senior positions.
Prior to being a manager, I was a senior engineer at SEP. I worked as the lead for many projects over the years, most of them being between three and six months in duration. An artifact of that type of quick projects was that, usually, one person was responsible for the technical vision of the application we were working on. That person was usually the tech lead.
How is a tech lead chosen? I am glad you asked. Often it is out of necessity. “I need a tech lead for project x. Joe Y is free, I think that he can do it!” “Joe, you are the tech lead on this project! I will be there to support you but you are the man!” Now this is a gross overstatement as it hints to an arbitrary nature for this which it is not.
Once the tech lead is chosen, they get to work and produce. If they succeed, we do it again, and again, sometimes on small or large projects. What we end up with is a very good but fully self-reliant engineer. This engineer may be less prone to seeking advice or other opinions and he may know “The right way to get this done®”. This is not what we want, long term.
With the above in mind, I took my idea to the people I thought to be in the best position to evaluate, and then execute the rough plan: Allen C., Adam L., and Dave M.
There were a lot of nodding throughout me presenting my idea and the reasoning behind it which lent some validity to my musings.
We set the following items as goals of the program:
- Give the trainee the benefits of learning from a master in their craft
- Establish a robust support system and teach the trainee to use it
- Engage the trainee in “real” situations and work
So we set forth a plan. The plan looks something like this:
- We will pair a trainee with a trainer for 6 months for the purpose of knowledge and practice sharing
- We will then transfer the trainee to a different team to pair with a different trainer for 2 months
- During that 2 months the trainee will be the tech lead for the other team
- After that 2 months the trainee will become the new tech lead and the trainer will pick up a new trainee
The plan worked. We have trained a total of two tech leads, both of which have “graduated” from the program, one of which is the official tech lead of one of the teams. We have one tech lead close to “graduating” and will be adding a few more trainees into the mix within the next few months.
I will try to lay out the specifics of what was taught in the program in a future post, once I have collaborated with the trainers to get their anecdotes.
