Behind the code with Dan Jankowski
Table of contents
When Dan Jankowski joined what would become Nutrient Workflow Automation Platform 15 years ago, he was one of six people at a small startup. Today, as VP of Technology for Nutrient Workflow, he oversees engineering, infrastructure, QA, and support for a product that serves customers around the world. His journey from support engineer to technical leader offers a fascinating glimpse into what it takes to build, maintain, and evolve complex enterprise software.
From hospital dreams to a small startup
Dan’s path to Nutrient wasn’t straightforward. Before joining the company, he had an unusual venture. “This might sound weird, but I was trying to build a hospital,” he recalled.
The project didn’t work out, but not longer after, a friend from his college band reached out about a small software company with a workflow product, inquiring if he was still working in IT and was interested in joining the company, then called Integrify. Dan was.
He took the role, joining a team of less than 10 people. And since then, he hasn’t looked back.
The evolution from support to VP
Dan’s progression through the company wasn’t planned — it was organic. Starting in support, he gradually took on more responsibilities: installations, cloud services management, automation. “Any manual task just becomes a bummer when it’s repetitive, and then you say, ‘How can I make it so that I don’t have to do this anymore?’” he explained. “So, that became something that I got pretty good at, the automation piece.”
The turning point came when one of the co-owners, Rich, approached him about a bigger role, noting that Dan knew so much about the product, that it would make sense for him to take charge of it all. Rich wanted to step back from running things and focus on coding, so he promoted Dan to his role.
The transition was sudden: “It was basically getting thrown into the fire, for all intents and purposes,” he said. Dan found himself managing not just support, but the entire engineering team. “And I learned a lot along the way, specifically how to be a manager and how not to be a manager.”
Understanding the product inside and out
One of Dan’s greatest strengths is his deep knowledge of the product. Even though he didn’t write most of the code, he knows how every piece fits together. “I understood any problem that any developer was having, because I understood exactly how the product worked, down to the nitty-gritty, because I did get in there, I did troubleshoot code, I did do things,” he said. “I didn’t actually make code as much as I’ve probably read every line.”
This comprehensive understanding came from those years in support, where he got to see how customers actually used the product. “I enjoyed it a lot, to be honest,” he admitted. “I think it was my favorite role, only because you get to know the customers. You get to understand why things are problems, and you get to give them solutions.”
The roots: A lifetime with computers
Dan’s technology journey began much earlier, with computers that required actual programming just to play games. His first computer was a TRS-80(opens in a new tab). “We’re talking five and a quarter floppies, green and black screen,” he said with a laugh. He explained that to play games, you had to program them yourself using a book.
At this point, Dan pulled out his old programming books from childhood, including “33 Challenging Computer Games for TRS-80™/Apple™/PET®(opens in a new tab),” and started flipping through the pages. As he explained how the books taught basic programming through flowcharts and game creation, he had a revelation. “I was based in Workflow before I even knew it,” he said, showing examples of flowcharts that don’t look all too different from the processes in Workflow Automation.
From the TRS-80, he moved to a Commodore SX-64(opens in a new tab), one of the first portable computers. “That thing weighed, like, 150 pounds,” he joked. “But it was the first computer I really, really started doing real programming on.”
Eventually, his focus shifted from programming to system administration. His first IT job was as a third-shift operator on an IBM mainframe, switching backup tapes and managing reports.
Managing people, not just technology
Perhaps the hardest part of Dan’s evolution has been learning to manage people. “Everyone’s different. So, that makes it hard to be consistent,” he observed. “It’s like parenting a little bit, right? You can’t put parameters in place and expect results in the same way. So you have to be a little flexible and yet stay rigid at the same time, which is difficult.”
The biggest challenge? “I hate giving bad news,” he admitted. “You’re not their friend — you are the manager.” But he’s learned important lessons, one of the main ones being how to help develop people at what they’re doing.
This focus on people extends beyond his team to the platform’s users. Just as managing engineers requires empathy and flexibility, integrating products and rolling out changes demands careful attention to how customers experience the software.
Integrating with the Nutrient ecosystem: Technology meets customer experience
When Integrify was acquired by Nutrient (then PSPDFKit), Dan faced a dual challenge: integrating a full product with Nutrient’s building block approach while keeping existing customers happy. The technical side was intricate. For example, Document Engine had to work differently in the cloud versus on-premises. “In the cloud, we’re using Managed Document Engine. On-premises, it has to pull it down into the cluster, so that was a hurdle,” Dan explained. Adding versioning and audit trails for PDFs, which the Web SDK alone didn’t support, was another complex piece of the puzzle.
Yet integration isn’t just about code — it’s about people. Even small visual changes can spark strong reactions. Dan recalled redesigning the process editor from bright, solid colors to a more modern look with borders and icons. One customer’s reaction stuck with him: “You can’t take my colors away! You can’t do this to us!”
The solution was gradual adoption. “We let it sit there and simmer for six months before flipping the switch, so people could choose to explore the new design at their own pace,” he says. This shaped his philosophy: “Change [in Workflow Automation] is slower, but it’s the way to balance innovation with stability for customers.”
For Dan, successful integration isn’t just about merging technologies — it’s about merging technology with empathy. By planning carefully and considering the human impact, he ensures the platform evolves without leaving customers behind.
A typical day (if there is such a thing)
Dan’s days are a juggling act. “A typical day for me is scrambling to try to get done what I’ve wanted to get done,” he said with a laugh. He wakes early, often logging on by 6 a.m. to connect with overseas colleagues.
His mornings start with going through Slack messages. The rest of his day involves 2–4 hours of scheduled meetings, fielding questions about bugs and features, working with professional services teams, planning releases, documenting changes, and testing. “I have to work really hard to get actual work done, and not just kind of organize thoughts and ideas from other people into something,” he said.
Advice for aspiring Workflow engineers
When asked what advice he’d give to someone joining the Workflow team, Dan emphasized patience and learning. “My recommendation is to take your time and learn before you’ve tried to act, because everyone’s gung-ho when they first start a job,” he said, noting that it’s best to fight the urge to be productive and first learn the ins and outs of the product.
For Workflow specifically, the complexity demands it: “You don’t have to be super productive the first couple weeks. Honestly, in Workflow, it’s better for you to learn what’s going on for those first couple of weeks, or even the first month, really,” he said. The learning curve is steep; Dan himself still discovers new things after 15 years.
He also encourages people to ask questions publicly. “People come, and they get hired, and they feel like they have something to prove,” he said. “Well, the best thing to do is ask questions. People don’t ask enough questions.”
Embracing Nutrient’s culture
As someone who has worked remotely for more than 20 years, Dan especially appreciates the culture at Nutrient. “Everybody here is smart,” he said. But he also mentioned the various social channels where people share pictures of their pets or their family members. He said it helps reinforce that everyone working at Nutrient is a person first. “At some companies, you don’t really get that,” he said.
He also values the openness of public channels. “If you’re on the outside looking in on those public channels, you can learn more about what the company’s doing,” he said, noting how he pays a lot of attention to the channels of other teams at the company. “I focus most of the time just on understanding what’s going on company-wide. You don’t get that kind of transparency in a lot of places.”
Most importantly, Dan noted, at Nutrient, there’s freedom to explore areas of interest. For example, when team members want to work on something outside their immediate role, he encourages it, noting that if someone takes time to learn something new, “it’s only going to increase your understanding; it’s going to make you a better engineer.”
What it’s really about
At the end of the day, Dan’s motivation is simple: “I just like helping people, either through the product, or through actual support calls, or internally,” he said. “If I can say that I helped people, I think I’ve done my job for the day.”
Whether it’s building features, solving customer problems, or supporting his team, helping others drives him. “And that’s why I was good at support; genuinely, that’s what I like to do.”
After 15 years with the same product and nearly two decades of remote work, Dan has built a career on deep technical knowledge, careful evolution, and a genuine desire to help people solve problems. His journey shows that sometimes the best technical leaders are the ones who never stop learning — and never forget that technology is ultimately about helping people.