Depending on the organization’s size, industry, line of business, and culture, and the general role of IT or product development, architects can have a difficult time knowing what their role is or should be in order to be effective. I often see CTOs at smaller companies acting essentially like the lead programmer. Sometimes this is necessary, or is just the “Way It Is” at a given company.
Moreover, this book problematizes that even further with the suggestion that “architect” is not exactly the role that’s needed at all, but that rather our work is in semantics and semiotics.
This chapter aims to help you define the scope of your role and perhaps expand it. Ultimately, you might well become the chief semanticist, principal semantician, chief designer, creative director, chief philosopher, or something similar to better reflect the practices here. Because everything is a potential subject of design, bringing your design mentality and toolset to a broader purview in the organization can help it be more effective, clear, and efficient.
I often observe that role clarity is a challenge in many organizations. It is difficult to rally around your job, invest in continuous learning, research best practices, and generally go all out to be the best if you’re not sure what it is you’re supposed to be doing or what success even looks like. Lack of role clarity accounts for considerable disengagement in organizations. People become ...