TL;DR: We're looking for a Senior System Analyst that will fit the boots of Functional Architect role for our platform. The main challenges are all about: scaling complexity, effective (& efficient) knowledge sharing, maintaining Ubiquitous Language, cultivating Domain Model that will correspond to the technical Solution Architecture. It's a chance for everyone who'd like to practice Domain-Driven Design w/o all the typical showstoppers that usually prevent it from happening.

Scaling is hard. Like really, really, really hard.

And I don't really mean traffic or user-base (which ain't trivial either). It's freaking hard to scale out both:

• domain complexity (by adding more & more functionality to the platform)
• engineering team (by adding more & more people to work on the platform development)

Some things are trivial when you can gather whole company around a single round table, but knowledge sharing and adding new 'stuff' gets exponentially more challenging once you get beyond 30, 40, 50, 100, ... people working in parallel on a solution that simply ain't fully comprehensible by any single person anymore.

Bigger team & more mature platform mean also more experiments (A/B testing), more sophisticated business ideas (because the trivial ones are already implemented ;>) and higher inertia (more factors to be consider while making any single change).

When complexity becomes painful

We've (Shedul/Fresha) learned all that as well. In practice, in more or less painful way. But to be honest, we're freaking fast learners & we never let lessons to drift away, this is not our style - we always strive to apply the learnings & evolve "our way of doing stuff" towards better. E.g.:

• we've felt our groomings were too much focused on obtaining the technical tasks to be implemented instead of building up a sustainable domain model (that backs up whatever functionality you'd like to built upon it) that we've decided to enhance our grooming formula with knowledge discovery/sharing exercises like Event Storming
• we've struggled with splitting more sophisticated business concepts into MVPs & their gradual enhancements, so we've come up with an idea of trying User Story Mapping as a technique to support such efforts
• key, "pivotal" entities on our platform became so over-utilised within all the possible use cases that we've decided to work on distinguishing clear Bounded Contexts to make sure that all concepts belong truly only where it really makes sense

One by one, we've realized that key Domain-Driven Design building blocks are fundamental to deal with the issues we're having on the daily basis: Ubiquitous Language, clear split into Sub-domains, Domain Events (& their handlers, representing the side effects), Bounded Contexts, sticking to transaction boundaries within well-set Aggregates, ...

The idea (of how to solve the issue)

Don't get me wrong - we're not zealously sticking to whatever's written in the Blue Book. There will be no hyped re-writing all the stuff to event-sourcing on my watch ... But we've learned that HAVING A MAINTAINABLE DOMAIN MODEL aligned with the code-base is crucial to keep a reasonable growth efficiency long-term, otherwise the model debt will eat us up.

That's how we've realized that we need someone to take care of it (as a custodian/guardian, not exclusively).

Someone to take the ownership over curating our Functional (Domain) Architecture (in a form of Functional/Domain Model), from the product (business) perspective. Someone able to cultivate it while it grows - taking care of its composition, modular split, purpose-orientation, quality. Someone able to determine what should be black-boxed, what should be exposed via contracts (to the "outside").

To put it bluntly:

We need a Senior System Analyst (position) who'd play the role of a Functional Architect of our ever-growing platform, preferably according to the mindset defined by Eric Evans in his Domain Driven Design (BUT if you find a better way & convince us that it is such, all other options are also in game).

What do we offer?

1. We're not a software house, we're a product (platform) company. There's something (really well-maintained) to take care of long-term.
2. We're a stable, quickly growing (exponentially) business - there's no issue of lack of customer interest. Quite the opposite.
3. We DON'T have the business VS IT separation. No shit. Null. Zero. We (product peeps & software development peeps) work together. ALL the time. We have no separate agendas/KPIs/goals. Product is key for EVERYONE in our company. Love it or leave.
4. Your workshop, your tools, your methods - are all up-to-you. As long as they work (deliver satisfactory results). And we're very straightforward when it comes to feedback: this work environment is brutally honest whether something brings the value or not. E.g. creating tons of useless diagrams is a burden & waste (because they have to be maintained). Your mantra should be: "minimize details & maximize understanding". Bottlenecks or knowledge silos will not be tolerated.

Let's clarify some things. But really.

1. We're looking for someone who'll pick up the mission (of organizing & developing of general Functional Architecture, that aligns closely the domain model & the code). No passengers, only drivers. No place for task-based people, we're looking for goal-based ones. You're supposed to come with a decent palette of tools, concepts, techniques & ideas - a sufficient "workshop" for a job we expect you to do.
2. Domain Model CAN'T be detached from the actual technical Solution Architecture - the only way for it to remain valuable is to keep direct correspondence between both. So we're not looking for a typical "Management Consultant" - able to draw good-looking boxes that do not really fit the reality ;)
3. If you're looking for a traditional "Business Analyst" kind of work ("I'll be translating business requirements to stupid IT people who understand only code" or "I'll reverse-engineer the Data Model & pretend it's a Domain Model") then please don't waste your (& ours) time - that's NOT what we're looking for.
4. This is NOT a corporate environment. One week is plenty of time, one month is an era. This is a work for people who try stuff, learn the outcomes & iterate QUICKLY. There's nothing wrong in being wrong as long as your learn from mistakes/outcomes & are able to move forward fast (in a fact-driven way).

Mission.
Ownership.
Taming the Complexity.
Scalable Knowledge Sharing (that supports EVERYONE's collaboration).
Domain-Driven Design.

Let's summarize

I keep meeting people (even during recent DDD Europe) who use to complain that they'd like to do DDD, but there's always something that prevents them from doing that:

• business (people) are not willing to participate (they prefer "dry" requirements as a contract with IT as a service provider)
• supervisors don't let them (because "this is not the way we do stuff here")
• developers stick to technicalities, instead of collaborating
• limited (/lack of) domain experts availability

Hear me. This is your chance.

We (here - in Fresha Engineering) know what DDD is. Our CTO supports it personally (he used to do presentations about DDD in local meet-ups as well), Product people (so-called "business") are more than available - locally, few meters away.

There's no excuse. Zero. We can do DDD if we want to.

The only expectation is that you'll be able to prove the value of whatever you're doing & "sell out" the effects of your work. That the "functional architecture" will be truly developed (due to shared effort, BUT driven by yourself).

Now, the question: are you up for the challenge?

P.S. The official job ad (for a Senior System Analyst) will follow within the next few days.

P.S.S. We're not looking for Functional Analysts/Architects only. If you're a Software Engineer who's interesting in building solutions according to DDD principles, we're more than happy to discuss career opportunities with you. Just please keep in mind we're primarily Elixir+Ruby+JavaScript workshop & being capable of using at least one of these tech is a must.