Wednesday, May 30, 2012

Evolution of a software engineering manager.

Many years of engineering and management experience and decision making strategy summarized in 5 simple paragraphs.

When I was in college, I learned about data structures and algorithms. Computer Science is basically a 2 dimensional problem: space vs time. How fast the code perform vs how much memory or disk space it needs? The goal is always to find the optimal balance between while trying to minimize both. I was good at coming up with solution so I moved up in rank.

When I became a senior engineer, I realized my job was really a three dimensional problem: space vs time vs complexity. More complex code, means more bugs and harder to maintain. One time inspiration, becomes a coding nightmare a year later, when I try to fix a bug but can't figure out how the oh-so-clever algorithm works. So the goal is to find the least complex code that meets the requirement while finding the optimal balance between space and time while trying to minimize both. KISS (Keep It Simple Stupid) became my golden engineering rule.

When I became an engineering manager, I realized my job became a 4 dimensional problem: space vs time vs complexity vs dollars. I had all the same problem as before, but now everything is measure against dollar / budget. Whether is person-hours, consulting dollars, missed opportunity, post-release technical support, etc. Every decision can be translated into different types of cost. My job is again, trying to find optimal path to balance and minimize all four dimensions of constraints. The good news is that complexity and dollar has strong correlation, spend the money upfront with great UI design will simplify requirement and simplify the UI will go a long way to minimize all the other dimensions. That's why I always hire the best UI/UX designer, and most senior engineers that I can find to seed the team, because they know how to avoid the traps of "over-engineering" a solution.

When I became an engineering director, I realized my job  became  a 5 dimensional problem: space vs time vs complexity vs dollars vs scalability. I'm referring to specifically the the scalability of the organization, the teams, and the inter-team and intra-team communication. This is a direct application of Conway's law. The desired product architecture must match desired organizational structure and communication processes. My job is to optimize the team, processes, and product architecture so each group can do their best to optimize the remaining 4 dimensions.

When I became an engineering vice president, I made it my mission to continuing my quest to articulate that one new key dimension. It took years of experience at each level before I found that one kernel of truth that clearly defines the role for each level. I have some ideas swirl in the back of my head, not yet a clear strategy. Stay tuned.