Shaping Our Pega Chapter’s Future: A Manager Onsite Day with Ideal Present Exercise

In my previous post, “Low Code Doesn’t Mean Low Engineering,” I reflected on how engineering depth reveals itself and not just in code, but in architecture discussions, refinement meetings, and the responsibility we take for what we build. A few weeks ago, I experienced that same principle from a different angle during a leadership onsite.

A Chapter Still in the Making Our Pega chapter leadership team came together for a full-day onsite: our chapter lead Raphaela and four Engineering Managers: Marga, Holli, Hannah, and myself. The interesting part is that most of us are still relatively new to the chapter. For me, it has been six months. Hannah joined in December and Holli started in February. In many ways, the onsite was both onboarding and forward planning. We began with something simple but surprisingly powerful: a timeline. Raphaela and Marga walked us through the early days about the first hires, the key decisions, the defining moments that shaped the chapter. For Holli, this was particularly valuable. Having joined recently, the timeline connected context to conversations she had only experienced mid-stream. At the same time, she enriched the discussion with insights from her previous Engineering Manager roles, offering an external perspective that challenged some of our assumptions in a very constructive way. Hannah, who joined in December, surprised us by checking her calendar on the spot and adding events we had nearly forgotten. She also remembered stories and milestones she had heard in earlier conversations some things that had faded for some of us but were still fresh in her memory. It was a reminder that “new” perspectives often see what long-timers overlook. Seeing the progression visually helped all of us connect dots that are otherwise easy to miss when you join later. It also reminded me that no team appears fully formed. Every structure, every process, every gap has a history, and understanding that history makes it much easier to shape the future.

Returning to the Mission After the timeline, we revisited our mission statement. Mission statements can sometimes feel abstract. But when you pause and read them together, they act almost like a compass. They force you to ask: Are we still aligned? Does this still reflect who we want to be? Maybe we’ll refine it in the future. Maybe it’s already exactly what we need. But taking the time to consciously bring it back into the room grounded the rest of the day’s discussions. It wasn’t just about solving problems. It was about moving intentionally. The “Ideal Present” Exercise The real turning point of the day came when Raphaela introduced an activity called Ideal Present, a planning method by Jabe Bloom. It was the first time I had encountered it and at the end of the day I became a fan (although I was questioning part of the activity if it was going to be useful and I saw later that it was done for a reason :) The structure is simple but powerful. You divide your thinking into four quadrants:

  1. Present Mess
  2. Future Mess
  3. Ideal Future
  4. Ideal Present Idea Present Canvas

We started with the Present Mess. And we were honest. We talked about areas that are not yet where we want them to be. For example:

  • Onboarding processes that aren’t fully standardized
  • Hiring challenges in a competitive market
  • Role clarity that could be sharper
  • No single driver for chapter-wide technical excellence

For the sake of the exercise, we intentionally focused on what isn’t working optimally. Not to criticize but to make reality visible. Then came the Future Mess: What happens if we change nothing? That conversation escalated quickly in a constructive way. We imagined:

  • Poor hiring decisions due to unclear expectations
  • Onboarding that takes too long
  • Reduced credibility as a Pega chapter
  • Lower motivation among developers
  • Talented people leaving
  • Limited ability to support business teams effectively
  • Decreasing cross-team alignment
  • Stagnating innovation

It was uncomfortable but necessary to imagine what can happen in the worst case scenario.

Worst case Senario

Imagining the Ideal Future After exploring the risks, we shifted to the Ideal Future. Not a magical utopia. Not unrealistic dreams but a best-case scenario if we intentionally shape our path.

  • We envisioned for example:
  • A standardized, reliable self-onboarding journey including technical and business knowledge
  • Clear expectations through a transparent career map and progression ladder
  • Strong retention and genuinely happy developers
  • Greater autonomy and influence within the organization
  • A chapter known for technical excellence and trusted advisory The energy in the room changed. You could feel the motivation rising as we described what could be. But the most important quadrant was still ahead.

The Ideal Present: Turning Vision into Action The final quadrant — Ideal Present — asks a deceptively simple question: If that ideal future is realistic, what do we need to start doing now? Some examples:

  • Reviewing and improving hiring and onboarding processes
  • Defining and communicating a clearer career progression path
  • Introducing more frequent reviews with stakeholders
  • Using our 20% chapter time in a more aligned and structured way
  • Exploring formats like a pre-hackathon workshop with stakeholders to generate more impactful project ideas
  • Clarifying the Engineering Manager role: something we recently initiated

Our next step will be to break the clusters we created down into actionable items and prioritize them by using the Eisenhower principle to separate urgency from importance. Only then does a roadmap start to take shape. And once it does, we’ll share it transparently with the entire chapter. Roadmap

Leadership Is Engineering, Too In my previous post, I wrote that engineering is defined by the responsibility you take for what you build. That applies to chapters and organizations just as much as to software systems. We are still building our Pega chapter. It’s not finished. It’s evolving. But spending a day stepping back from delivery and acknowledging the mess, imagining the risks, and deliberately designing the next steps felt like high ownership. And maybe that’s the real common thread: Low code doesn’t mean low engineering. And growing a chapter doesn’t mean low leadership and it doesn’t just mean growing in size. It’s also about how we grow. Both require intention, collaboration, and the courage to actively shape what comes next, so we build the right thing, with the right quality and the culture we truly aspire to in the long run. That’s how we create a strong foundation for something we can genuinely be proud of in the end.

I’d like to thank our Pega Chapter Lead, Raphaela and my fellow Engineering Managers, Marga, Holli and Hannah for their feedback on this article and even more importantly, for a productive and enjoyable onsite day.

Written by Elif Schaefer, Engineering Manager (Pega)