2018 was a year that we focused on our co-workers’ happiness and satisfaction at work. Creating a place where people can grow and happily spend one-third of their life was always our goal as the founders of Pragmatic Coders. We had long debates on how to measure this aspect of our work. After that, we came to a few conclusions described below.
Flat organization structure
First of all, we always tried to design the Pragmatic Coders as a flat-structure organization. We were always aiming for keeping it as flat as possible without introducing any old-time fashioned management roles.
But… The flat organization does not mean it does not need any structure. In our case, after long discussions and many experiments, we distinguished four roles (two organizational and two projects/process-focused) that structure our environment and the way we work.
- Projects/Process-Focused Roles:
- Product Owner
- Scrum Master
- Organization-Focused Roles:
- Account Manager
- Servant Leader (we are still looking for a better name for this role – any ideas?)
As you can imagine projects-focused roles are standard Scrum roles and probably do not need any explanation (read more in Scrum Guide). Although, we are not dogmatic in terms of software development methods. We rather use those tools that work and make sense in particular contexts. We are also pretty pragmatic in terms of our approach and this is why not every project and team at Pragmatic Coders have a Product Owner or Scrum Master on our side. Even if we learned that this is probably the most effective approach to cooperate with our clients, in some cases it does not make any sense to assign PO and SM to a small, short project with 2-3 developers team.
Work Organization Specific Roles
Besides of standard Scrum roles, we introduced the Account Manager and Servant Leader roles.
The rules are simple: every client needs to have an Account Manager assigned and every co-worker needs to have a Servant Leader assigned.
Account Manager role is probably self-explanatory for most of you. Such a person is responsible for keeping good relations with our clients, onboarding new clients and solving high-level issues.
In terms of Servant Leaders, it is more specific to our company. In our case, such a person is responsible for our co-workers’ happiness, personal growth as well as shaping those people roles and creating a place for them in our organization. How do they do that? Read below about our 1-on-1, 360s, Happiness Surveys etc.
One important thing – those are roles, not positions. Although we have at the moment 4 person to perform all of those roles, none of them is assigned to just one of them. That makes recruitment for such roles more difficult since we are not looking for corpo-like Scrum Masters or Product Owners but rather for Leaders who are able to wear a specific hat when needed and perform well in various context.
There are a few rules: such as Product Owner and Scrum Master in the same project cannot be the same person, and Product Owner and Servant Leader cannot be the same person in one team, since Product Owner is usually too much involved into the teamwork and she/he might lose the right perspective when working on people’s growth.
That approach allowed us to create a repeatable process around our cooperation with our clients and internal work organization as a software development agency.
The direction of the company
Last year we also managed to clarify the general vision of Pragmatic Coders and the values that we want to build this company on. Together with our team, we described it as a “Pragmatic Coders Manifesto” – a guideline for every person in our company on what we value the most and why.
I will probably publish a full article about this Manifesto and how it works after we will have more data on its impact. In short words, we want to be a company that is a great and stable place to work and a place where everyone could grow. We want to work on interesting projects and this is why all of us have professional who care about good relations with clients, think about business value and focus on continuous learning.
How to collect and give feedback, and help to grow
When Pragmatic Coders was around 25 people, collecting and giving feedback was pretty easy. Usually, all of that has been done by me and Marcin (Pragmatic Coders co-founder) alone. Despite our other responsibilities, we were able to regularly talk with everyone in the company, collect and give feedback. Now, with 50 people on board, we would have to do only that. Probably we would miss some important things too. This is why we had to figure out a better process for measuring a team’s satisfaction and happiness
An initiative started as an experiment by two of our Servant Leaders – Piotr and Igor brought good results. Now every person at Pragmatic Coders is under some Servant Leader’s protection. Those are the go-to person in case if something goes wrong or if a person is looking for support or willing to provide some feedback. The 1-on-1 meetings are performed every month. Servant Leaders collect feedback and solve all the issues on their own, in the Servant Leaders’ team, or escalate them to us if needed.
360 feedback sessions
None manager could give you as good feedback as your colleagues from your team. This is why we introduced 360 feedback sessions that happen regularly. Servant Leaders collect feedback about every developer in a few important dimensions and share it with the person under review. That process, as well as 1-on-1, is for the person under review only. We as founders do not receive any information about people ratings etc. We designed as a personal growth tool, not employees rating tool.
Even if we always try to look at our people from their personal progress perspective, especially when they ask for rising up their salary, we do not need data from 360s for that. We try to keep that salary review process separated from 360s.
Read more about team feedback here >>
Work satisfaction survey
Opinions without data are usually useless. So we were looking for a good way to measure satisfaction and happiness, and to collect data about our actions and the impact we made. Without data, we might consider every new idea and action we performed on a company level as progress. But it does not need to be true every time.
We started with something as simple as satisfaction survey. Everyone at Pragmatic Coders answers a few questions about their happiness and satisfaction at work. Collecting answers monthly helped us understand if our actions lead us in the right direction or if they make any impact at all. Again, we do not focus on the particular person’s answers. We (as company founders) do not even know who gave each particular answer. Although Servant Leaders do know that and sometimes use it to track some problems. On our level, we just focus on aggregated (in a few dimensions) data and trends.
If we made a bad decision on the company level, usually data will show it after the next survey. Of course, the same is visible after something really positive happens.
Effects of measuring satisfaction
In 2018, we took many steps to create a place where people can grow and work in a positive environment.
Establishing certain roles in every team allowed as to stay flat, but a well-organized organization with effective communication. Writing down a manifesto was an incentive to evaluate company goals. Manifesto helps us to stay focused on our most important values. When we introduced 1-on-1 meetings and 360 feedback sessions we gained a more accurate assessment of the work of each team member. And finally – introducing a happiness survey gave us insight into the moods in the company.
All those aspects of satisfaction measurement complement each other and give us a view on the company from different angles. For sure that’s not all that can be done in this area, and next year we will strive to obtain even more valuable information that can we work on.