When I was teaching/running district tech, the principal at the school had a piece of paper taped to the file cabinet next to his desk which had a list of things to do to help build a team. One of the items was “Feed Your Troops”.
At Atalasoft, that was a thing that we did figuratively as well as actually. The picture above is a cake that Christina Gay got for the office for my birthday one year. I returned the favor by making her a cake for her birthday with a hand turkey on it, since her birthday is close to Thanksgiving.
We also routinely had pizza lunches, beer o’clock on Friday, and the occasional bacon day (I’ll save that story for another day). This is the actual feeding of the troops. The figurative was another thing entirely.
Lou Franco and I had a problem in that he and I were the most highly experienced engineers at the company and we had a decent number of talented junior engineers and a few moderately experienced engineers. The problem with that is that we needed more engineers in the moderately and highly experienced bins. The solution to that is time and opportunities. Not every engineer has the time (or thinks they have the time) nor are there are always opportunities.
Lou had a great idea, which was to do some lunchtime seminars. He chose the topic of the GoF design patterns and rather than do a presentation each week himself, he assigned a pattern to one of our junior engineers. The engineer would have to explain the pattern and how it worked and also where it was used in our code base. Some engineers took the task seriously and presented in depth. Some engineers clearly had just copped the wikipedia page. The fun part was the “where is it in the Atalasoft code base” portion. After the junior engineer did their bit, one of the more experienced engineers would list off the other places it was. Funny thing, before these presentations, I had never known the GoF patterns under their names. This is partly because I independently invented most of them at some point in my career or encountered them reading someone else’s code. They didn’t have names; they were just what you used when you had certain classes of problems. Nifty!
Later, I set up an independent study program where junior engineers picked topics of study and I would would work through it with them. Some of the topics included Scheme, C, and ray tracing in F#. Anything coding related was fair game.
We also did regular company staff meetings where we had a rotating schedule of people who ran the meetings. Very often, the choice of the curator of the next meeting was a game of “not it” but hated or not presenting for a group of people is a valuable work skill. We also tried to set aside time for work or non-work presentations. Sometimes they were technical, sometimes they were show and tell. They were always valuable.
One thing that I remember talking about with Lou about the overall process was that in a small company like ours, we were free to make our own rules. What do you mean you can’t take time to teach and mentor your cow workers? How can you not? One of the things I liked about Atalasoft was that I felt like I had the opportunity to make it into an engineering organization that I most wanted to work in. Certainly, it had room for improvement and we actively tried to steer things in that direction.
If you take the time to thoughtfully create a structure that is engineer friendly, then your engineers will want to be there, even through the inevitable slog work. If you are actively involved in professional development, you will build a better, more capable team. How do you achieve that? Feed your troops.