Alumni Profile: Christian Jungers

Tell us what you did immediately after graduation and leading up to the founding of CM3.

Following graduation, I went to work with an enterprise networking company, Cabletron Systems, that later became Enterasys Networks. I took the position because I wanted to expand my development toolkit and to be able to make good software. The networking company allowed me to get closer to hardware and to better understand embedded development.

I was there for 4 years, right up to the dotcom bust. So, there I was with my severance package trying to figure out my next move when my friend and fellow CMU grad, Scott Ziolko (HSS ’01), called with the proposition: “Have you ever thought about starting your own company?” We spun it up pretty much overnight, and were joined shortly afterwards by another Carnegie Mellon friend, Chris Stratis (HSS ’01, TPR ’05).

That was the beginning of CM3 Consulting which, by the way, stands for Carnegie Mellon 3, a name that was graciously given to us by another group of CMU grads who’d conjured it up for their industrial design company!

Founding your own company is not for the faint of heart. What was it that drove you to take the leap?

Coming out the MSE program, I knew I had this great toolbox. I had new skills and a suitcase of lessons-learned. I had a stack of white papers rolling around in my head about approaches to specific problems, assessments of those approaches, and suggestions on how one might tackle this or that problem going forward. And, coupled with all that, I now understood process because of my time in the MSE and I possessed the technical skills to fully-execute.

But in the real world, you don’t have an opportunity to apply these best practices. When you work at big companies, you may not have much control or power. You’re stuck in someone else’s process or hierarchy. Opportunities to do the great things that you know you should be doing — that you know would improve the product, the solution, and the company — are either scarce or non-existent. In part, this is why I jumped at the chance to start CM3 — so that I could put my knowledge and best practices to good use.

CM3 and Fino merged in 2013 after you collaborated on a project with Fino’s CEO, Brian Fino. You went on to serve as their CTO and now you are also leading the charge as the CTO of Therm, a Fino spin-off. So, can you tell our readers a bit more about Therm?

Essentially, we are building a cloud-based sales platform tailored for energy retailers. These are the companies that actually provide the electricity or gas that is piped into your home by a utility company.

Over the last decade or so, Fino has done a lot of work for energy retailers. And, over that time, we started to realize that this was a market that was ripe for change. The calculations needed to provide the best prices to consumers for a wide range of offerings across massive geographic markets was not trivial. And the industry was still using some fairly rudimentary tools that were extremely labor intensive and error prone. We knew we could do better.

You can think of Therm as a SaaS solution for these energy retailers, much like Salesforce. Not only can these retailers configure the platform to automate the pricing calculations based on a huge range of variables, they can also track and integrate the solution into their existing sales and servicing infrastructure.

This is a pretty big departure from your work as a boutique consultancy. What sort of challenges did you and your team face with this transition?

The biggest challenge is actually the most exciting part of this entire venture: building expertise.

Pretty much every single day for literally the last three years, we have been saying “Oh, now I get it!”.

We were familiar with the energy space; we’d been working in it for years. But as we started digging deeper into the finer details of the sector, we kept asking questions that were — for lifelong energy sector folks — really fundamental. But the answers to those questions often revealed some sort of insight that was so simple that it was actually quite revolutionary to insiders — it was a “can’t see the forest for the trees” type scenario.

It comes down to the fact that we are sort of naive experts. What I mean by that is we have worked with a lot of these companies for years. They know us. They trust us. But we are still outsiders. So we can ask a lot of those really “simple” questions I mentioned. It’s like a get-out-of-jail-free card for getting to the root of the problem these folks needed to solve.

Gaining that expertise has been hard-fought. And, interestingly, I think it is actually the biggest value-add we have in this product. I'm a proponent of domain-driven design. For me, that really means your code, your architecture, your data should mirror reality. And the challenge was: if you go to ten different energy retail companies and you talk to ten different people at each of these companies, you will get 100 different pictures of the industry — different terms, different processes, different ways that they think things happen.

Nobody is on the same page. Because they all have their Excel spreadsheets and they put whatever columns they wanted in there, whatever made sense to them, and then passed it on. And so, just as a whole, the industry is just in a sad state in terms of data integrity, process, and consistency. While it makes what we are trying to do a really big challenge, it also makes it one of the most exciting opportunities of my career.

What is it about that challenge — reconciling so many different siloed perspectives in the field — that you find so exciting?

It is exciting because, at its core, this is a blue sky project. There are some competitors in this space, but they have been only tackling the problem piecemeal. We are really building a system that unifies the base needs of the industry through abstraction. That’s never been done before, and is only possible if you understand the field holistically.  

It’s also exciting because we are actively shaping the state of the practice. One of the reasons I started my own company after leaving CMU was because I wanted to apply the best practices I had learned. I wanted to be that “Agent of Change” that the MSE program trains students to be.

We are several years into our discovery phase of this company and we feel we have a pretty good grasp of what needs to be done. Right now, we are within a few months of having a good model of the entire business around energy retail marketing. There is, of course, a small enough list of things that are still unknown. But, from the pricing all the way to the trading side, we’ve folded most of the business into our models.

Now, when we get a new client, at some point — and they don't usually tell us this, but you can feel it —  you realize that they've woken up to our approach: It’s better. Our models are consistent and universal. Because we asked the right questions, because we were disciplined in our approach to software, we've come up with this abstraction of their entire business, end to end. As far as we can tell, that's never existed for them before. We hope that this is changing the entire way this sector is using software to do business. It’s changing the state of the practice.

With spinning off a company like Therm — one that is in an opportunity-rich arena, you could say — maintaining a disciplined approach to development would be a challenge in and of itself. How do you manage the trade-offs and set priorities in that sort of wild-west environment?

Actually, a bit of that ability comes back to the Studio capstone project we did in the MSE program.

Studio was all about attempting to do everything right.... And failing miserably. You wanted good architecture. You wanted good modeling. You wanted all the best features completely fleshed out and ready to go by launch. The whole process should be as right as possible. But it isn’t going to be. Invariably, the project is going to come apart somewhere if you try to do everything perfectly and in parallel.

You have to prioritize.  A number of years ago, I came across an article by Michael Lopp called “Bits, Features, and Truth”. In it, Lopp put forward that there are three personas at play. The “bits” are the technical folks. The “features” are those advocating for the functionality that users really want. And the “truth” is typically the project management, those concerned about schedules and roadmaps. Lopp points out that you have to have all three, and that they have to be comfortable pushing back against one another. If you don’t, the project will become unbalanced and fail.

If you ask someone to build you a desk and they give you the world's most perfect drawer, it's useless. You don't have a desk. So if there's only a “bits” person, it's very easy for engineers to just go down rabbit holes. And then you get the world's most perfect drawer and no desk to put it in. If there is only the “features” person — it's like this ramshackle, beautiful-looking thing that as soon as you touch it, it falls apart. Or it just keeps getting delayed to develop one more feature until it never comes out at all. And without truth, you just never get anything done. So you need all these people fighting. That’s how, I’ve found, the priorities get set in the best possible way — through compromise and consensus. We all have a piece of the reality that we are trying to address through this solution, it requires all of our perspectives to figure out how to get there.

Speaking of perspective, through your time working with a lot of different sectors with FINO and now delving into Therm, what do you see as a big issue on the horizon for software engineers? What problem should we all be paying attention to?

I think, for me, what it comes back to is that disciplined approach.

So, as an example, one of the early battles between Brian and I as we were building out Therm was security. From my perspective, let's start with security and authentication. Bake it in from day one. Our whole system will have it nicely architected throughout everything.

But Brian pushed back, "Well, when we have one client, we just white-list their IPs to have access to the site." I was floored. It was lunacy from an engineering perspective.

Well, for six months while the initial users went through beta testing of the system, we did not have authentication. We whitelisted IPs from our client. And it worked. And the time we didn't spend building authentication allowed us to build features and get to market that much faster. And eventually, folding in proper authentication best practices throughout the application became our highest priority and it got done right to support our first production-ready clients.

We had known, at some point, we would have to come around and fix that. But that was a choice. It was a part of the design. I could push against Brian’s point, but I couldn't really debate the principle that if we worked on the authentication and didn't have the functionality the client actually needed, it didn't matter. It's not a product. We don't have a sale. It was a priority that was set by the “bits, features, and truth” model. We all get in a room and try to find what we feel is the right compromise in terms of features, timelines, etc.

And that phrase “what we feel is the right compromise…” is where I — and probably anyone working in software development at this level — am still working on the discipline side of things: Feeling isn’t rigor. It's not repeatable. It's not engineering. It's entrepreneurial but it's not engineering.

That's going to be the next big challenge, I think. How do we bring the rigor we apply to reasoning about reliability or security or scalability to the actual process of deciding what to design and when. At the end of the day, you can read as many case studies as you want and develop your own sense of intuition. But intuition is not measurable.