🌿 What I'm taking with me

Published on
7 min read

May 14. I got the call. It has been two weeks, and I have been sitting with it long enough to know what I actually want to say.

I was laid off from Penn.

Honestly? After a few days, the part that stuck with me was not the call itself. It was the arc. The people I worked with, the work I got to do, and the unexpected door that opened along the way.

The team that pushed me

Penn is full of genuinely talented developers. I learned more there than I had in any single stretch of my career. Not from any one person, but from being surrounded by people who took the craft seriously.

I started on the platform side and ended up doing feature work too. That range matters more than I appreciated at the time. Platform work teaches you to think about leverage and stability. Feature work teaches you to think about users and shipping. Doing both in the same org pulled my thinking wider than either would have on its own.

A few things that stuck:

  • Code review as a teaching tool, not a gate. I learned how to give a review that made the other person better, and how to receive one without ego.
  • How seriously the senior engineers took ownership. Not just shipping a thing, but staying close to it after it landed.
  • That the bar for "done" is higher than I had been holding myself to. Being around people with that bar quietly raised mine.

I am a different developer than I was when I joined. That is not something that fits in one resume line. But it is the part that travels with me.

Senior work without the senior title

For a long stretch, the work I was doing was senior-level. I led pieces of features end to end. I was the person other engineers came to with questions. I was making architecture calls that shaped what we shipped.

The title did not follow. The structure kept shifting, leadership changed, and the goalposts moved more than once. For a while that bothered me. After enough cycles, I started to see it differently.

The lesson I am taking from it: titles are downstream of structure. They depend on org charts, headcount, and who is in the room when the decision gets made. The work is yours. The skills are yours. The title is not always in your hands.

That reframe is the most valuable thing I learned there, and it did not come from any standup or design doc. It came from watching the gap between what I was doing and what got written down about me, and deciding which one I was going to trust.

Where the diverted energy went

Here is the part I did not expect.

When the goalposts kept moving, I quietly redirected. Energy that I would have spent chasing a title at Penn went into side projects instead. Reading. Building. Picking up tools and domains that were not on anyone's roadmap for me.

That redirection turned out to be the most important career move I made in those years, and I made it by accident.

Side projects opened a door I did not know was there. They led to a role I would not have been a candidate for otherwise. I am now Principal Data Solutions at Collingwood General and Marine Hospital, a domain entirely outside the software-product world I came from.

Curiosity-led learning compounds. I have written that line before, and the last year is the most literal proof of it I have had.

A new domain entirely

Hospital data is its own world. The shape of it, the constraints, the regulatory layer, the way information moves from clinical systems into something a human can reason about. I am learning the ins and outs of it from scratch.

Some of what I am working through now:

  • How data actually moves through a hospital. Where it originates, where it pools, where it gets stuck.
  • Pipelines and medallion architecture as a way to organize raw, refined, and reporting layers cleanly.
  • The difference between software-product instincts and data-platform instincts. They are related, but they are not the same.
  • Working with a manager who is, frankly, a data engineering beast. I have not had a manager I learned this much from in years.

The pace of learning is steep, and that is the point. I had forgotten how good it feels to be the least experienced person in the room on a topic that matters.

What I am bringing the other way

The cross-pollination has surprised me. A lot of what I picked up on the platform side at Penn carries directly into the hospital-data world.

What has translated cleanly:

  • Azure DevOps pipelines. Setting them up, tuning them, keeping the CI/CD discipline tight. The lift in dev velocity once that layer is in place is real.
  • Branching strategy and code review as a teaching tool. Automated checks before merge instead of after.
  • Treating data work like software work. Versioning, reproducibility, testability. Pipelines as code, not as ad-hoc scripts.
  • The engineering instinct of "if you did it twice, automate it the third time." That instinct is genuinely useful in a data-platform setting.

I came in expecting to be the one learning a new domain. I am, but I am also bringing something into it. Software-engineering best practices accelerate the maturity curve on the data side, and being the person who can do that has been one of the best parts of the role.

What carrying both roles taught me

For a while I was doing both. The full software role at Penn and the data role at CGMH, in two completely different industries. I do not recommend it as a default, but it gave me a sneak peek of how I actually work under pressure.

What I learned about myself:

  • I can take on more than I thought, if the work is interesting enough to pull me through.
  • My skillset is broader than I had given myself credit for. Software, platform, data, civic tech, all draw on the same underlying instincts.
  • Time, energy, and boundaries are skills, not personality traits. I got noticeably better at all three by being forced to.
  • Confidence is downstream of evidence. The evidence came from doing the thing.

I would not have signed up for "manage two demanding roles in different industries" as a development plan. But it ended up being one. And the version of me on the other side of it is steadier than the version that went in.

What I am taking forward

Skill security is real. Job security is an illusion. I have written that before. The last two weeks made it more literal than I would have liked.

When the call came, the thing that kept me steady was not certainty about what was next. It was knowing what I had built up inside of me. The reps. The breadth. The proof that I can pick up a new domain and contribute in it.

Those do not get laid off. Those come with me.

A note to myself

You will be tempted to write the bitter version of this post. Resist it. The bitter version is smaller than the truth.

The truth is this. A team helped you grow. The goalposts moving did not break you, it redirected you. The redirection opened a door into a domain you had never seen before. And the manager on the other side of that door is teaching you things you would not have learned anywhere else.

Stay curious. Keep reading. Keep building. The next chapter is already underway.

Titles are downstream of structure. Skills are yours. Onto the next.