Early Days
Like so many other engineers, I started programming in high school. After school, I would spend hours hacking away in Basic and Assembly, working on various projects. At that time, everyone already knew about computers, but computer programming was esoteric and mysterious. Programming was like Lego—countless pieces did nothing individually, but together, they could create an infinite number of cool things.
I earned my degree in computer science at Cal Poly in San Luis Obispo, where the motto was—still is, in fact—“Learn By Doing”. When we studied compilers, we wrote a compiler. When we studied ray tracing, we wrote ray tracers. And so on.
Paid to Program
College was fun, but the working world was even better. I coded all day and was paid for it! For years I happily programmed, taking on increasingly senior roles in interesting domains like neural nets, signal processing, 3D graphics, and typography.
Over time, opportunities arose to apply my problem-solving skills to various non-programming challenges: getting the best work out of teams, finishing projects on time, ensuring that the right work was done… The tougher the problem, the more satisfying it was to solve it. But I began to realize that I felt the most satisfaction when I solved tough challenges as a part of successful teams.
I worked with strong teams—not unusual in Silicon Valley. The teams always came up with good solutions, but not every one was successful. If our projects were canceled or our finished products were not well received, the joy of coming up with a good technical solution was subdued. When my teams produced something our customers loved, the team was successful, and it felt great.
Management Roles
After years at various startups and big companies, I stumbled into my first management role. The previous manager had left, and I was the senior-most member of the team, so I stepped up to ensure nothing fell through the cracks. I was energized by the success of the team, and by my role as their manager! I had a more comprehensive view of the situation, more involvement in the decision-making process, an opportunity to influence overall policies, and buy-in from both management and engineers. I was regularly addressing big challenges and, more fundamentally, making my teams successful.
Since then, I have joined other companies in individual programmer roles. But I have always gravitated back to management positions where I could seek the opinions and guidance of others, improve my skills, and gain a deeper understanding of management and leadership. I discovered that I have a knack for management and enjoy addressing its challenges. As much as I enjoy coding, I add more value on the management side of the house.
Blogging
As my experience and the size of my reporting organizations grew, I regularly found myself working with new managers or engineers who were making the transition to management. They needed both formal and informal coaching sessions, during which we could work through issues and develop strategies. Increasingly, I spent time mentoring and sharing what I had learned. I began writing internal blogs for my management team and engineers to explain problems, decisions, and strategies. Eventually, I realized that the same content could be useful to an external audience.
So, I decided to write this blog. I aspire to be something like Joel On Software was back in the day, or Rands In Repose is currently. Both authors host personal sites based upon their experience as engineering leaders, and both do it well. I will strive to reach their level of proficiency, if not their production, since I plan on keeping my day job.
I believe the important topic of leadership and management in software engineering is underserved. New engineering leaders often have great technical skills but less insight into leadership and management techniques. In some small measure, I hope to correct this deficiency. And so, I start this blog.