The Napa Years

This post will be even longer than what I usually write, almost like a short novel. (Disclaimer: it might take longer than one toilet break to finish. ;) ) It will be a story of extremely talented colleagues, supportive supervisors, growing organization and a journey of one physicist. Acknowledging the risk of sounding like self centered dick, it will be a story about me and my professional career at Napa Ltd.

Prologue

I didn't struggle much at school. I learned things quite fast without the need to repeat. Especially mathematics was interesting and I got good grades. Later in high school I selected extended levels in mathematics, physics and chemistry.

When it was time to select the place for my studies, selection criteria was to pick the most difficult one. I went to study Technical Physics and Mathematics at the Helsinki University of Technology. My major was Physics and minor Computational Science. This was the first time I really needed to study hard. The challenge felt good. I mainly selected courses based on their difficulty rather than on their usefulness: quantum mechanics, functional analysis, etc. I frowned upon economics and applied mathematics (the topics that could actually be useful in business world!) I did study a bit programming and one course of differential geometry that would come handy later. During the summers I made two special assignments about positron annihilation measurements, one practical and one computational.

Early Years

In 2007, when I had completed almost all my studies, I started to look for a thesis researcher position. Coincidentally, there was a Talent-IT fair at the campus. I wandered around and found the stand of Napa company. I had never heard of it, but they seemed to do things I could maybe contribute in and they had a master's thesis position open. Worth mentioning is that I had experience only in two programming languages: Java and FORTRAN. Insidentally they were also present in Napa's stack at the time. :)

Tom Sundell, who I had met at the fair, contacted me later and we agreed that I would come for an interview. There were two alternative topics: some kind of pattern library or a study about the hull surface representation methods. The second one was closer to what I had studied. While writing the thesis I got familiar with NURBS surfaces, Coons patches, T-Splines and learned a lot more about the NAPA program.

After completing my studies I joined the NAPA Technology Unit as a Systems Analyst. Mainly that was a fancy name for a programmer. Back then there was a clear separation between core developers and GUI developers and I was proud to work with the core challenges.

All developers were part of a big pool from where they were assigned to different projects. Releases were planned for one year at a time. I don't really know how that was done, I had zero visibility (and interest at that time) to the topic. Business people came with specifications and programmers wrote code. Everyone was an individual contributor and a specialist. My field was geometry. Some of the things I'm proud of from that time include upgrading the finite-element 2D mesher, implementing an envelope surface for a given set of planes, participating in renewal of surface modeling and implementing free-form deformation into the program.

Work was in a way easy for a developer, since all you needed to worry about was the implementation. But with multiple overlapping projects, the resource allocation became challenging. Some key contributors were needed in almost every project. I remember that my closest colleague, the more senior geometry expert, was simultaniously in 5-6 projects! At that point it was clear that some kind of change was needed and the organization was ripe for it. Sense of urgency was there.

Adopting Scrum

We had already made some experiments on using a scrumbut for some of the projects. In the early 2012 the company had made a decision to make a radical organizational change, start working in teams and define a process oriented way of working. Teams were formed around products or feature regions. My team was called Model team and we worked with modelling related topics. Teams elected their own Scrum Masters. I was really interested and got elected. And so our distributed team (people in Finland and India) started learning Scrum.

Actually every developer in the company (at least in Finland) had gone through a Scrum Express training by Mr. Lare Lekman. All Scrum Masters were then trained with Professional Scrum Foundations and certified and Product Owners were trained as Professional Scrum Product Owners. 

We also formed Communities of Practice. One gathered together the Scrum Masters and it was facilitated by our Chief Scrum Master. But then this person was assigned to another, more urgent role and the position was left open. There was an internal job ad for the position of Software Development Director. I applied.

I didn't have enough experience to fill this role, but I maybe had some potential. In the end the role was split. Our Chief Quality Officer took the ownership of Software Development process, but I acted as his right hand man and owner of the Scrum framework. I became the Chief Scrum Master. Maybe I could describe our work in a following way: we discussed things together, he wrote specifications and followed metrics and I interacted with the teams. I think it was fun and we had a weekly meeting where we discussed the Agile topics on a sofa. My workplace was in an open space with lots of whiteboards and I called it the Agile Center of Excellence. :)

During this time I went to a couple of really useful trainings. Agile Coaching and Leadership was about what the name implies and then Leading SAFe course. Both were really influential and had a big impact on my work life. At that time I also started to facilitate retrospectives for the whole company.

Entering Management

One day in the late 2013 my boss invited me to a meeting together with the Chief Quality Officer. There were going to be some changes to the organization and I was given an opportunity to take a lot more responsibility. My boss used to be also the supervisor for our Release Team that guards the quality of main codeline, provides and maintains tools and other stuff. He was also the owner of our Release Process. He moved to another role and I adopted all that. I became the owner of the whole Software Product Creation value chain. This meant pretty much all actions that take place in development before the software is given to customers. In addition it meant that I would be a Product Owner and supervisor for the Release Team. At that time I decided that what ever problem someone had with our technology function, processes or results, I would take the responsibility. No bouncing the problems around and asking the person to find someone else. I would take full responsibility and later then find out who could help me fix things.

My boss had been sitting in his own room, but I wanted to sit together with my team. (The room was next to the team room and was still available for private discussions and calls.) At the time there were three members in Finland and two in Romania. The guys were brutally skilled. I really understood that in an expert organization being a supervisor is mostly about removing obstacles and making sure your team can work effectively. The best implementation decisions always come from them. My role was to set priorities and make decisions when needed. Now afterwards, the time when I worked together with my team was the high peak of my working life so far.

As the Release Process owner I also wanted to plan the releases differently. I had been very unsatisfied with the level of transparency on the plans. As I wrote earlier, previously developers had no idea how the releases were planned. Specifications were just dropped on their laps. I decided that we should make things more public. In 2014 we arranged our first Release Planning Day and I have described it in more detail in this previous post. I think I can take some credit for kick-starting the practice, but most of it goes to the organization. People, especially Product Owners and Product Managers, came in prepared and played their role well. I remember one colleague saying something like "Thank you. Now for the first time I get an overall picture of what's happening in this company."

Due to some organizational changes and other events, my team size was diminished until at one point we only had me and two release engineers. We started a recruitment campaign and this was the first time I ever recruited anyone. We got one new team member into Finland and into India. Then for the first time we had a Release Team member in all our development offices.

Side jobs and other activities

Before the management I was also an Industrial Safety Delegate for a few years. I was also the first Shop Steward. Both of these side jobs originate from my urge to keep the game fair. As a mathematician I like defined rules and it would be awesome if the world followed such rules. Unfortunately I have also learned that it doesn't really happen in practice. That's why it's better to stay agile, adapt to different situations and update plans accordingly.

One nice side job was also acting as the internal facilitator for strategy renewal work. It was a real vantage point over all functions in the company. And really, really interesting.

I also worked as an internal auditor. Napa has an ISO 9001 certified management framework and holding internal audits is part of the model. Again, a really good chance to learn more about different parts of the company and how they interact.

I also

• helped arrange the first NAPA hackathons, 
• also some coding dojos at Helsinki office, 
• held a Coding School for kids, 
• gave a presentation at Scan-Agile and Projektipäivät,
• a few presentations at annual NAPA User Meetings,
• participated in the DD-SCALE project 
• created Twitter account for the company
• started a mentoring program for new software developers at Helsinki office
• exchanged experiences with other companies 
• was a member and secretary for the Technology management team
• wrote a SAFe case study with Maarit Laanti  

 Resolution

While being responsible for so many different things simultaneously I started to drop balls. Or maybe not totally drop, but I felt that I cannot do the things as well as I wanted and as well as they deserve to be done. I really liked being the Chief Scrum Master and manager for the Release Team, but those were responsibilities that could be easily transferred to others. So I did. Reluctantly, but from my own initiative. I felt that the organization would get the biggest bang for a buck when I would concentrate on the value chain and activities that go across the function boundaries.

At this point I also became the secretary for the Portfolio Management Team. I had been driving the adoption of Scaled Agile Framework (and become a certified SAFe Program Consultant) and felt like the owner of the framework. I wanted to bring more structure to the way things were decided on the top level. Unfortunately the process for introducing new Epics was largely unknown to organization in general. I helped to transform the Roadmaps from purely technology and development focused into something that better takes into account also other activities like service development and marketing. The experiment is still ongoing.

During this time I had come to a decision. I want to see how things are done in other companies. To see in practice if I could make an impact and to help other companies too. And that is why my journey will continue from now on somewhere else.

Epilogue

Napa has been an extremely good place for me to grow. During the past nine years the company has gone through a big transformation. From individual responsibilities to team responsibilities, growing organically both in number of employees and in revenue. I feel I've grown with the company. I have faced challenges and opportunities. I'm grateful to all my colleagues, my supervisors, everyone who have supported me.

I hope my departure will also be a chance for Napa to do things differently. I'm sure they will continue finding new and better ways of working. Especially the new products and the investment in improving user and customer experiences sound really promising.

I will miss this place dearly and it will always have a special place in my heart. And who knows, maybe I'll one day return. Hopefully I haven't burnt any bridges behind me. Godspeed Napa! And enjoy working together!