You can’t really know where you are going until you know where you stand.

Last month, we presented our Progression Framework to the public, who welcomed it.

Developing a clear and systematic framework for our employees’ career progression was, first and foremost, a project of great internal importance. A progression framework became critical for managing employee engagement and performance after reaching a certain company size. 

Our company now employs almost 400 people. Establishing the criteria for career advancement on a case-to-case basis is neither sustainable nor justified. It’s important to communicate what is expected in each role clearly. That way, goals become more easily attainable, and motivation to reach them increases.

You can explore our Engineering, Design, Quality Assurance, and Management progression frameworks here, or keep reading to learn more about our process of coming up with them.

As we grew as a company, we started getting more and more inquiries about career progression.

Then in spring 2021, a loose team of seven people with different roles and backgrounds started to get together to discuss how the company would benefit from standardizing expectations for moving forward with one’s career. 

Between sessions, we would research and study various publicly available frameworks, from Microsoft and Google to smaller companies. Progression.fyi proved a great resource here, and recommendations are in order for anyone interested in the topic.

Interestingly enough, we all independently came to similar conclusions. So slowly we started to develop our ideas about titles and levels further.

I don’t mean to pretend we invented the wheel here. Progression frameworks are nothing new, and neither are the constituent parts that make them. However, you shouldn’t just settle for the first generic framework that comes up in your Google search. You want a custom one suited to your company’s and your people’s needs. Just like the custom digital products that we build.

So far, we’ve developed four high-level frameworks – Engineering, Design, QA, and Management. They consider the specifics of each type of work, but they follow the same model. 

Each title and level we’ve defined belongs to one of the three tracks:

Here, we ventured slightly away from the classical approach that includes individual contributors and management only. Instead, we felt that the tech-lead track works great with our structure and the fact that we’re a digital design and development agency, not a company that sells ready-made products.

The track is, in a way, an alternative route for a senior employee who may not want to go down (or up) the management road. It includes a lot of responsibility, organizational tasks, and mentoring but doesn’t include people management. So it’s not something that comes in between individual contributors and management, but a career path in its own right.

The original team comprised seven people representing management, HR, some engineering teams, and QA. We approached the problem from different angles and contributed with our knowledge and experience.

With the original idea coming into being in the spring of 2021, we were able to pilot the project to QA at the end of 2021. Things moved quickly from then on, and we had Engineering and Design covered by mid-2022.

We used a phased approach, which I recommend to anyone embarking on a similar adventure. Developing our framework in increments, we were able to adapt on the go, and I still believe just throwing this at the whole company would be reckless.

Note that Infinum’s progression framework does not represent the current job roles at our company. Working on this project, we decided to “dress for the job you want, not the job you have.” The idea was not to capture where we are currently but envision where we might be in a few years.

Some of the roles included in our framework are yet to be filled. We are growing every day, both as a company and as individuals. Maybe we don’t have a Lead Engineer level 2 in every one of our teams at the moment, but in a year or two, we might have several.

Spoiler alert: both have been great. Who’d have thought people generally prefer knowing what is expected of them instead of guesswork and vague ideas?! Ha.

All jokes aside, it’s a well-known principle in psychology that a challenging yet attainable goal produces the best outcomes. Conversely, non-specific goals like “I will do my best” tend to motivate people far less.

For some people, the framework served as a sanity check and encouraged them to work harder. Seeing it all in black and white made them think “F%&$, I’ve been here for two years, and I’m still level 1, I need to get it together.”

Our framework also got excellent feedback outside the company. Before the page went live, we sent out individual sheets per request via LinkedIn. The response? Let’s just say that people jumped at the opportunity to see a hypothetical career path.

Because we believe in open source and giving back to the community is a part of our culture, our progression frameworks are now publicly available on our website. When we have more, we’ll publish more, and hopefully, many others working in the industry can benefit from them.

Developing our custom career progression framework was a journey, and like with every journey, you learn a lot about the destination and yourself. Putting this all into perspective made us think about the company we are and the company we want to become.

It’s great to see that our employees have responded so positively to it, and we hope it will help guide them in their career paths. We’re always learning and growing; the progression framework is no exception.

Check out the page every once in a while. It might not be the same as you left it.

If you’re familiar with iOS development, there’s a big chance you know that architecture is a touchy subject. We won’t go over that particular problem here since there are a lot of good posts on the web that already cover that. Instead, we’ll talk about how we tackle this issue at Infinum.

Apple’s proposed MVC architecture wasn’t bad for many of our smaller apps, especially when we started with iOS development. However, as our projects grew more extensive and complex, it became harder to handle many cases cleanly and consistently. So, we started searching for something else and finally came across VIPER.

When we started diving into this new architecture, our iOS team counted ten people, so we were already a bit late to the party. Now that this number has doubled, I cannot imagine working in an agency environment without a well-defined project architecture. Of course, if you are a one-man band, that doesn’t mean you don’t need a suitable architecture for yourself and all future developers coming to the project. But the need for this is even more apparent in an agency environment.

VIPER is not a silver bullet by any means, nor is any other architecture. But when you have circa 40 projects being switched between 20 people where the assignments can be anything from a 15-minute bug-fix to a couple of months worth of development, you want to have a well-defined and standardized architecture that everyone understands and uses correctly. That allows anyone from a junior newcomer to a seasoned smart-ass to know the where, what, and why, making it easier to get the job done correctly and fast.

To give a concise introduction, the VIPER architecture is an implementation of Uncle Bob’s clean architecture. To put it into the context of iOS, what used to be a (possibly massive) UIViewController is now a module consisting of 5 elements:

There are a bunch of great posts on the web that talk about the VIPER architecture for iOS apps. Many don’t go into accurate detail about how to implement this architecture in real life.

When we started with VIPER, we tried a couple of different approaches on real-life projects. This allowed us to figure out what works and what doesn’t quickly. Here are some of the methods we tried that didn’t end up feasible:

After a couple of months of trial and error, we got to some excellent solutions and approaches:

These are just a couple of broad points we iterated over. There were also other minor points like naming, folder structure, standardization of navigation, data passing, etc.

We finally distilled the actual architecture implementation into templates. We open-sourced VIPER Xcode templates on Github with an in-detail description of how they should be used and why.

It is not easy to fully grasp the theory and practice behind VIPER. We think we found a way to utilize all of its merits because our implementation stays true to the theory behind it, but we also made the learning curve much less steep by using templates and well-defined rules.

The main issue with VIPER, and to some degree with other non-standard architectures, is that you sometimes have to work against the native API’s standard usage. There is no such thing as free abstraction, but we were willing to pay for ours since the pros outweighed the cons.

After more than three years of using VIPER, we’re still trying out new things now and then to stay sharp, but we’ve adopted it as a company-wide standard for any project with more than a couple of screens or lasting more than a couple of sprints. We’re still on the VIPER bandwagon and very happy to ride along.

My day job is writing iOS apps. My main hobby is writing, recording and producing electronic-rock music. Sometimes these two seem more similar than one would think, and in this article I’ll try to explain how.

First some background information – I’ve been pursuing a career in programming for a while now, and the last couple of years I’ve focused on doing iOS development. But I’ve been a music buff and guitar player for a long time now.

I also do electronic arrangements, production and some recording with my current band. I did all the pre-production for our two short albums, did some mixing and also played and recorded every instrument except the drums and piano.

The band is called Plastic Knives, and this is what it sounds like:

The idea for an article that compares programming and music came to me after talking to one of my colleagues. Now and then he likes to inquire about the progress of my musical side-project. After one of these chats, he told me,

So here are a few ways in which my programming relates to my music production and/or writing. If I get any programmer or musician to try and do the other, that would be more than awesome.

If you’re not writing, let’s say, JavaScript, you’re going to need an Integrated Development Environment (IDE). Likewise, if you don’t have an analog tape machine and a massive mixer, you’re going to need a Digital Work Station (DAW). This is often a big and somewhat intimidating software for a novice user. You need to take your sweet time and learn how to use more complex commands. The thing is that it will pay off in the long run.

You can do a lot of stuff with some googling as you go along. This can get you so far, but, in the long run, you really need to invest more time and read a book or a more in-depth tutorial. Music writing/production and programming both have a constant learning curve, and as soon as you think you know everything, something new comes along that proves you need to learn more.

Contrary to reading a book, talking to someone who has experience in the field takes next to no time. However, even a 10-minute conversation with a senior programmer or experienced musician can have a dramatic positive effect on your work. This generally applies to a lot of fields, but when it comes to technical work that has a lot of creativity to it, this becomes even more apparent.

If you want to have a good final product, you need to iterate. A lot. Rushing leads to bugs in songs and strange noises in user interfaces.

In your Digital Work Station (DAW) there’s a lot of sound tracks, effects and options turned on most of the time, just like there’s a bunch of classes, objects, processes, threads and resources which interact with one another in a computer program. If you don’t follow some basic organizational rules and patterns, you’ll end up with spaghetti and a headache.

Obviously, you get better at this with time and experience, but sometimes this can be ridiculously flawed on both fronts. This happens mainly when you get new ideas during the execution process.

No one is proud of the first few programs they write, and no musician wants everybody and their mother to hear their first couple of songs. This is normal – practice and results come in time.

Sure you can do any of these things with a basic knowledge of math, but knowing a little more goes a long way. Whether we’re talking about algorithms or wave editing, understanding what’s really going on under the hood will give you the ability to implement your ideas more easily and expand the horizon of your creativity.

Most days I can’t do without a fresh pot, and I’ve found a lot of programmers work the same way. Also, contrary to popular belief, most rock musicians don’t go for the more expensive under-the-counter stuff.

When staring at a chunk of problematic code, or listening to a troublesome song section, it’s good to know when to stop. Often a solid break or, even better, a good night’s sleep can help you spot and iron out the issue.

It’s no secret that having something that occupies you beside work is a great way to clear your head, whether it’s similar to your work or something totally different. I enjoy doing both music and programming. I hope you share a similar passion for your work and have a cool hobby that helps you in the same way creating music helps me.