What’s in a name?

Robbert Kooiman vierkant
Robbert Kooiman
mei 10, 2022 · 4 min lezen Engels
Lego checkin

In his blogpost “From solving applications to solving processes,” my colleague and friend Nick Gies described how we developed as a team — from Functional Application Management to Functional Business Analysis — and what this entails. In this new post, I want to focus on our team’s continuing journey.

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.

Rocket auditorium

A new perspective

At Schuberg Philis, my role turned out to be very different, and my initial assumptions were proven to be quite incorrect. As soon as I landed at Schuberg Philis, it became clear that the structure I had been used to was simply not there. At first this made me uneasy. How would I know what to build? How did I find out what the business requires? What was the bigger strategy?

Fortunately, as with all change, as soon as I started to embrace it, I started seeing possibilities. A new perspective came into view: what if we built an application landscape the way we actually wanted it to be?

Then it started becoming clear to me what the role of “Functional Application Manager” actually meant at Schuberg Philis. We get the chance to architect a landscape, enhance the business processes, and implement solutions the way we see fit. While at first this can seem overwhelming, I truly believe this ultimately leads to the best solutions.

A new name

The title of this bog post is a question: “What’s in a name?” It’s a relevant question, because — as you may have read my colleague Nick’s post — last year we renamed our team from “Functional Application Management” to “Functional Business Analysis.” When we now recruit colleagues, the title for the role we offer is usually “Functional Business Analyst.” I don’t think this quite captures the role in full, but it is a great starting point.

During interviews with potential new colleagues, I notice that the job title sounds quite challenging to them. This is a natural response, as Schuberg Philis does things differently from a lot of other companies. And that’s why I believe it’s time to introduce a new title for our role: Full Stack Business Analyst.

Going Full Stack

So what does a Full Stack Business Analyst do? In our work, we are responsible for implementations — from concept to adoption. This means we spot opportunities, study a subject, get stakeholders behind our ideas, select vendors and implementation consultants when needed, and kick off the implementation process.

During the implementation phase we become experts on the processes and the systems we are implementing and continue to recruit other project members from within Schuberg Philis. After the implementation is complete, we stay connected to the initiative as an expert, are responsible for its adoption, and continue to support the organization.

I believe that is what “Full Stack” means, and it’s great to have a job with such an impact, supporting the growth of Schuberg Philis — all the way for 100%.

Does this sound interesting to you? Good news! We are actively looking for colleagues, so if this story sparked your interest, feel free to get in touch for a cup of coffee. We look forward to meeting you.