In the world of software engineering, roles were created that were loosely organized around traditional engineering functions. A software engineer generally was the person doing the actual development of the code that ran the program. Titles were introduced as a way of differentiating skill levels, such as “junior”, “senior”, “intern.” Later, as systems became increasing complicated, the role of the “Architect” was created. Again, fashioned along other more traditional job categories, the architect’s primary job was to “design” the system, with documentation passed to engineers who used the “blueprints” to do the building of the system. In theory, the role definitions delineate a clear set of lines and career path opportunities within largely technical pursuits. In practice, the lines are much more blurred. At Malauzai, we’re trying to blur the lines even further. That’s not meant to imply that we shun job titles or career growth paths. We not only employ architects and engineers, but also have managers and executives within our engineering organization. So what do I really mean by blurred lines?
At Malauzai, I have the lofty title of chief technology officer. Functionally, I represent our technology organization on our senior management team. I spend lots of my time looking after budgets, meeting with customers and prospects, and keeping our management and executive team up to date with details about our engineering operation. I also spend lots of time guiding and leading our engineering leadership group, which has direct responsibility for different facets of the entire organization. While all those tasks are generally considered to be part of a CTO’s job, I consider myself first and foremost, an engineer. The CTO title actually has more to do with responsibility than it does with skills and experience. That’s not to say I haven’t been around this industry for a long time, which I have. It’s more to do with the fact that, ultimately, somebody has to lead, and take responsibility for the organization, with all the successes and failures. I like to say that when something goes right, it’s my team’s success. When something goes wrong, it’s my fault. But there’s a deeper truth in there. As an engineer, I believe that my engineering skill needs to be strong enough to match my general functional leadership. That’s not to say that we don’t have experts in specific areas whose knowledge far outweighs mine, but in general terms, the CTO, I believe, needs to really be the company’s most experienced engineer. Again, not an expert in all specific technical areas, but certainly with a more than conversational understanding of those areas.
Which brings me back to the architect title. I believe a CTO needs to be an organization’s chief architect. As a chief architect, general architectural responsibility is implied. Going a step further, a thorough understanding of the software being developed by the organization should be required. Thus, the CTO does not simply live at the mercy of an engineering organization’s individual choices, but plays an active role in designing and guiding those choices. Is that “micromanagement?” I don’t believe so. To me, it’s a natural function of a general progression for an engineer.
Engineers should care about code. Whether they’re an intern, or the CTO, they should be conversant in their organization’s code base, and take an active interest in the development of that code. For that simple reason, all members of the Malauzai engineering organization write code. The CTO, the VPs of Engineering, the designers, the engineering teams. The amount and specifics of the code vary widely, but the outcome is what’s most important. Our engineers know that the day of a manager may look very different from the engineer’s day. But on balance, both the manager and the engineer should have an understanding of the value of each other’s contribution. For many engineers, the value of the manager’s contribution should be made clear by guidance and leadership, with obstacles constantly being removed, in order to ensure the engineer’s success. For the manager, not only is the completion and quality of an engineer’s work a signal of their contribution, but by having that manager getting their hands “dirty” in code, they also gain a valuable insight not only into what the engineer is facing, but get a chance to participate in a much more tangible way with the organization’s success.