What I Look For When I Mentor an Appian Developer

Appian certification is a floor, not a ceiling.

I say this not to dismiss it — certification requires real work and the exams cover meaningful ground. I say it because I’ve worked with certified developers who were still learning to debug production issues under pressure, and with uncertified developers who already had the instincts of a senior architect. The certification measures what you know. It doesn’t measure whether you can think.

Mentorship is about building the thinking.

The Gap Between Knowing and Understanding

Most Appian developers I’ve mentored can tell you what a CDT is, how process models work, what a record type does. That’s knowing. That’s what you get from the documentation.

Understanding is different. Understanding means you can look at a data model you’ve never seen before and identify in ten minutes which parts are going to cause performance problems at scale. It means you can read a process model and anticipate where it will deadlock under high concurrency. It means you can hear a requirement described in a stakeholder meeting and already be thinking about the three ways it could be implemented and which one is probably right.

You can’t teach understanding directly. You build it through deliberate exposure to real problems, guided reflection, and a lot of uncomfortable questions.

The Three Habits I Try to Build

1. Start with the data model.

This is the habit that separates developers who build working applications from architects who build maintainable ones. Almost every Appian performance problem I’ve ever diagnosed traces back to a data modelling decision made early in the project and never questioned.

The discipline I try to install: before you write a single expression rule or build a single interface, spend time on the data model. Who owns this data? Where is it sourced from? How will it be queried? What are the relationships? What changes in the future?

Most developers skip this because it feels slow. But I try to build this habit:

The data model conversation is never time wasted — it’s time borrowed from debugging.

2. Read the logs before you read the code.

When something breaks in production, the instinct of most junior developers is to look at the code first. That’s often the wrong starting point.

Logs tell you what actually happened. Code tells you what was supposed to happen. Those two things are not always the same.

I spend time in mentorship sessions on log literacy — teaching people to find the right logs (stdOut first, always stdOut first), read a stack trace without panicking, correlate events across log sources, and form a hypothesis before they start modifying anything.

The shift I’m looking for: from “let me change something and see if it fixes it” to “let me understand what happened before I touch anything.”

3. Ask what the edge case is.

The most expensive bugs come from handling the normal case correctly and forgetting to think about what happens when something unexpected occurs. The process has 10,000 active instances instead of 100. The user submits the form twice in two seconds. The integration endpoint returns a 500 error after a 30-second timeout. The file uploaded is 500MB instead of 5KB.

I ask developers to finish every design conversation with: “And what happens when…?” Not hypothetically, but specifically. Pick the most likely failure mode and trace it through the system. If the answer is “it probably breaks,” that’s a problem to solve now, not a risk to accept.

The Moment I Know Someone Has Crossed the Threshold

There’s a shift that happens in most developers I work with closely, and I’ve never found a way to force it — only to create the conditions for it.

It’s the moment they stop asking “how do I do X in Appian?” and start asking “should I do X at all?”

That shift from implementation thinking to design thinking is when someone stops being a developer who uses the platform and starts being an architect who understands it. It’s not about knowing more features. It’s about having enough context to question the approach before committing to it.

I’ve seen this happen in three months. I’ve seen it take two years. The pace depends on the person, but mostly it depends on the quality of the problems they’re exposed to and whether someone senior is asking them the right questions when they work through those problems.

That’s what mentorship is for.

Why I Think Certification Gets It Wrong

I want to be specific here, because “certification is overrated” is a thing people say without explaining what they mean.

Appian certification is good at testing: knowledge of platform features, ability to apply documented patterns, familiarity with the Appian way of doing things.

It doesn’t test: architectural judgement, debugging under pressure, the ability to model a complex domain correctly, performance intuition, knowing when to break the Appian-recommended pattern because the specific situation calls for it.

Those latter skills are the ones that determine whether a developer is effective on a real project. They’re also the skills that take the most time to build and the most deliberate effort to teach.

What Good Mentorship Actually Looks Like

Not weekly calls going through documentation. Not code reviews that only say “this works” or “this doesn’t.”

The things that actually develop these skills:

Pair work on real problems. Not toy examples — actual production issues or real feature development, worked through together, with the mentor narrating their thinking out loud.

Post-mortems on mistakes. When something goes wrong (and it will), the most valuable conversation is the one that traces back to the decision that led there. Not to assign blame, but to build pattern recognition.

Deliberate constraint. I sometimes give developers a problem and add a constraint they wouldn’t naturally choose: solve this without using a process model, or model this without an extra CDT, or explain this design in two sentences to a non-technical stakeholder. Constraints force creativity and expose the gaps.

The uncomfortable question. The question that challenges an assumption they haven’t thought to question. “Why does this need to be synchronous?” “Where does this data go if the process fails?” “Who else needs to see this, and can they?” Developers who have been asked good questions eventually start asking them of themselves.

The developers I’ve seen grow the fastest aren’t the ones who worked the hardest on memorizing the platform. They’re the ones who stayed curious about why things work the way they do, asked uncomfortable questions, and were willing to be wrong before they figured out how to be right.

That’s the raw material mentorship works with. Everything else is just structured exposure to good problems.

Getting Started

Are you an Appian developer looking to make the jump to enterprise architecture, or an IT leader trying to build a high-performing low-code team?

Subscribe Now for weekly architectural breakdowns, or reach out to Contact us to discuss platform strategy and technical mentorship.