It is now two and a half years ago that I applied for a position at Schuberg Philis. The job title was “Functional Application Manager” and I came in (as one does) with my own set of assumptions. Specifically: for me job title implied that I was going to manage a full stack of applications. In other words, I would be an expert on tools that we use like Jira, Confluence, SharePoint, and many others. To me, “managing applications” meant being the in-depth expert and providing support to end users.
What my experience had taught me
This perspective stemmed from my previous work experience, where I was used to having an Enterprise Architect around telling me what the application landscape should look like. We also had several functional experts who owned the business processes, and ultimately there was me: an application expert responsible for implementing the processes in several different applications.
In practice, this top-down process was rarely successful. The enterprise architect, working from his or her proverbial “ivory tower,” would come up with an initial idea for a setup. But by the time it reached me, having passed through several management layers, I saw quite a few issues. Those issues then had to be communicated back through the same management layers. The final result, after a lot of difficult discussions between managers, was often a suboptimal solution and, more importantly: a very annoyed me.
As stressful as it was at times, though, this experience was formative. Ultimately, I strongly came to believe that the process should be leading, always keeping the technical limitations in mind when designing a solution. For example, what I often saw was that a great process was designed, but then at implementation time we still had to disappoint a lot of people. The existing tools would simply not be up to the job. And implementing new tools was often too complex or costly — and thus not allowed.
