How context building and delegation of authority can strengthen small organizations

The entire company at a feedback workshop in Lodz, Poland during October 2018.

Introduction

I’m a big proponent of the belief that “if you want to change the world, start off by making your bed.” ¹ This approach works just as well for organizations, in my opinion. If they want to change the world, they need to take care of themselves first. The best way to improve your company is by focusing on the development of its employees. If they are empowered to make quality decisions and take action, the chance of them accomplishing something outstanding collectively increases exponentially.

In this article, I’m sharing a story of how our company faced challenges related to our identity as well as financial and engagement crises, and how we eventually overcame these problems. My hope is that our obstacles and our solutions can help you to deal with challenges you might be facing right now. As a result of building more context and delegating authority, we managed to make our teams more collaborative and engaged, improve their skills, and strengthen our organization overall.

Why we needed to change

We are a software development company in Poland. Our organization consists of teams that are comprised of 1 to 6 people, who work on projects, typically one project per customer. Our main focus is on building web applications and server infrastructure for startup companies. The entire staff has been working remotely since the beginning of 2006. We have had around 20+ employees since we began our journey to become a more open organization.

Every company faces challenges. There are always short- and long-term needs that have to be balanced appropriately. If we focus too much on the former, we may go nowhere. When we do the opposite, we may never reach the future that we are trying to achieve. At some point, we encountered a combination of both types of problems at Ragnarson. As you might expect, we didn’t handle these issues as well as we could have initially. Despite our best intentions, our organization was far from our ideal vision. The problems were getting bigger; it was becoming harder and harder to fix them. We knew that we needed to change our approach.

Development of our team

We are enthusiasts of a T-shaped skillset where individuals possess specialties with deep expertise in one field in conjunction with broader general knowledge. This type of skillset makes them better specialists and enables them to collaborate with experts from various fields. Moreover, T-shaped individuals tend to look at problems more holistically. They usually appreciate the complexity of a modern world and tend to have more mental tools at their disposal. This all leads to a greater capability among such individuals, which positively impacts their productivity. ²

The problem with our organization was that it did not effectively develop such individuals. At the time, we had mainly one expectation from our software developers - writing software for our customers. Project management was mostly taken care of by Marek, our project manager. Internal chores and issues faced by the entire organization, with some exceptions, were addressed by a dedicated team. This meant that most of our staff was rarely exposed to the organizational challenges. This worked well in the short run and boosted the number of billable hours, but it introduced numerous problems in the long run. Most importantly, the very narrow scope of education and training that we were offering to our teams limited the improvement of their skillsets and their mindsets.

Mutual responsibility and commitment

When the organization begins accumulating problems rather than effectively solving them, it becomes harder and harder to improve the situation. In our case, we noticed two main obstacles that were especially hampering our ability to tackle day-to-day challenges.

First, “management”, as we called the group responsible for internal matters, was a bottleneck. ³ The number and variety of issues, real or perceived, became too overwhelming for them to handle efficiently. No one had enough time, and everything was assumed to be a priority. Many of the existing problems were quite complex, and potential solutions were far from obvious.

Secondly, developers perceived the shortcomings of our organization as due mostly to failures of the management. At least, this is how it felt from the management’s perspective. This heightened the “us versus them” alienation, which led to additional stress, demotivation and a lack of collaboration.

We needed to somehow unite both groups and induce in them a mutual level of ownership over our organization’s challenges. The idea was to diminish or remove altogether the bottleneck so that we could concentrate all of our efforts on solving the rest of our problems.

Development of our organization

Unique value proposition and recruitment

Another issue that we were facing related to attracting talent. This is one of the biggest common challenges across our industry. Most agencies, including us, are quite indistinguishable from the rest. Even if an agency builds its brand on 2-3 “unique” features, there are probably at least a few others, who are claiming exactly the same distinction. There are numerous combinations of factors used to attract talent, such as salary range, perks, remote/non-remote work, technology stack, types of projects, brand strength, company culture, internal structure, quality of management and leadership, or the level of bureaucracy. These all contribute to making an organization unique. However, our combination was not especially unusual. We thought we needed a stronger unique value proposition (UVP) to attract our target group of potential employees.

A lack of a firm UVP led to an especially demotivating conclusion. If we don’t have anything “special” to offer, maybe there is no reason for us to exist. Our clients could simply be served by others. Our developers could find a different organization to join. The feeling of not being distinct and/or innovative strongly inspired us to self-reflect and pursue potential solutions.

Sales and negative cash flow

The software development market has been very favorable for suppliers for quite some time because of high demand. There have been more projects and customers to serve than there are available developers. Despite this strongly positive trend, we faced the opposite problem; we couldn’t find enough projects to keep our developers busy. An unpredictable sales pipeline and negative cash flow were definitely immediate concerns.

Diseconomies of motivation and human resources

The last of our critical issues related to human resources. As long as the team was relatively small, things seemed to go fine. However, when we got closer to 30 people and tried to leverage economies of scale, we ran into the problem of diseconomies of motivation. The amount of various HR-related problems grew exponentially. Many of them stemmed from a sense of dissatisfaction with certain aspects of our organization. For example, we lacked a clear career path and a transparent process for promotion. It became apparent that our company structure and internal processes required more attention.

Feedback workshop, October 2018, Lodz, Poland

The road to improvement

Ultimately, our issues in the short-term included negative cash flow and demotivation of the team. In the long run, we needed to overhaul how we developed our individuals and how they collaborated and took responsibility as well as make our sales pipeline more predictable and identify and craft our unique value proposition. It was quite a lot to tackle, especially when we acknowledged our past failures. Nevertheless, we stepped back to get a bird’s eye view of the situation and started drafting our plan.

In hindsight, our high-level improvement plan seems quite obvious. We needed to:

• focus on training and engagement of our employees
• create an environment supporting collaboration and mutual ownership within our organization
• once we solved the two issues mentioned above, our entire team could address the rest of the challenges together ⁴

The actual steps that were necessary to accomplish this weren’t quite as clear. The devil was in the details. If it was easy, we wouldn’t have had such problems getting there in the first place. We needed to introduce numerous changes of varying complexity and weight. It wasn’t an overnight successful rollout, but rather a steady and relatively slow process of recovery. We tried different things simultaneously. It was quite chaotic and experimental at first. The idea was to test several theories, see what happens, and react with further improvements and adjustments as necessary. Below, I describe the most important changes in no particular order.

Admitting problems

One of the first steps we took, inspired by Alcoholics Anonymous, was admitting our problems. We gathered the entire company together and clearly stated that we needed help. This opened up a discussion about the various issues and the difficulties we were facing in solving them. It was important to emphasize that all ideas were welcomed, but they also needed to be followed by actionable next steps. It was a symbolic start that allowed us to raise awareness and inspire people to participate in the solutions.

Making communication channels more open

Opening our communication channels was a relatively easy change for us to make. Nonetheless, it brought about some surprisingly positive results. Even though we had a company-wide online tool for announcements and discussions, oftentimes, the exchange of opinions and debates were taking place on Slack. Because of some long-forgotten outdated decisions, many of our topic-specific channels were private. In the past, everyone who wanted to join could ask for access, and it was always granted. However, when all channels became open by default, it was much easier to follow different discussions and participate in them. Some people were surprised to learn how many different things were happening and how much effort each of them required.

Delegating authority and control

One of the biggest and most challenging shifts to make was empowering our staff in decision-making. Grzegorz, Mariusz and I own and lead the company. Historically, we were expected to have a decisive voice in the most important matters. Nevertheless, we weren’t interested in micromanaging and controlling every decision. It was far from a culture where subordinates must always include their supervisors in a carbon copy (cc) of every email. In spite of that, we might have inadvertently still been too controlling. Moreover, the way in which we shared our opinions and interacted with our team made it difficult for them to become more autonomous. This was an important contributor to our bottleneck at the management level.

First, Grzegorz, Mariusz and I needed to change our mindset. If we wanted to have numerous competent decision-makers within our organization, we had to let them actually make decisions. In many cases, it wasn’t that hard. We didn’t have strong controlling natures, at least in comparison to what we had observed among our peers. In the case of high-stakes decisions, especially those that impact our revenue stream, we’ve been gradually shifting responsibility to the team as they have become more self-sufficient and self-confident.

At the same time, we have been changing the way we communicate our opinions and feedback. Instead of being supervisors, we serve as advisors. The team was supposed to listen to our opinions if we gave ones, listen to others, and make their own decisions together while bearing the consequences. We emphasized that we could be wrong about something, and our advice was just a suggestion that didn’t have to be followed. In the end, it was less about how we expressed our opinions and more about how others were perceiving what we said. The message that they communicated among each other shifted from “they want me to do this” to “think about that while making a final decision.” Overtime, it became more and more natural for all of us, and the staff was willing to make more serious decisions with little or no involvement from management. It was probably one of the most impactful improvements. The process of change has been slow and chaotic at times, and it necessitated a few feedback cycles. This communication style and leadership approach continues to be something we hone.

Extending financial context

From the financial perspective, our team had always been well-informed. We employed an open budget that was accessible to anyone at the company, which included information about our revenue, expenses, profit, and rates. There was a separate spreadsheet for each month that provided an overview of our financial past. However, in the context of our cash flow problems, we needed something more. We created a tool that enabled us to forecast our financial situation and shared it with the entire company. This gave us a better overview of our runway and the balance of our accounts. Most of all, it helped the team to model different scenarios and develop their decisions and efforts with more of an awareness of the potential financial outcomes and consequences. This positively influenced their ownership over various decisions by helping them better understand what was at stake.

Engaging the team in bench management

When some developers don’t have a billable project, our industry typically refers to them as ‘sitting on the bench.’ In the ideal world, demand for developers from external projects should be immediately satisfied. No one should have nothing to do at any given time. In reality, the bench helps us to balance an unequal supply and demand flow. Oftentimes, when you need additional developers, you don’t have anyone available, and when the demand is stagnant, you have people waiting on the bench. Even within a small company like ours, bench management can be complicated. New projects tend to emerge simultaneously; the supply side seems to follow a similar pattern. When it rains, it pours. This gives rise to numerous possible scenarios often with multiple dependencies and limitations.

In the past, bench supervision was the sole responsibility of the “management.” We met once a week, with some rare exceptions, and analyzed all of the possibilities. If we decided that an employee might fit one of the projects, we discussed it with the candidate afterwards. This approach, apart from repetition, severely deprived developers of:

• participating in the broader discussion
• understanding the complexity of a particular decision
• contributing their ideas and potential solutions

Unsurprisingly, as a consequence, this lack of involvement led to poor ownership and a diminished sense of responsibility for the projects in the long run.

The obvious solution was to ask people sitting on the bench to participate in our meetings, and we also invited anyone who simply wanted to join. The less obvious part was ceding control and responsibility over the decisions. Bench-sitting developers were expected to select a project for themselves or find some other task to do. The changes we made did not have an immediately apparent impact since their positive influence also hinged on other improvements (e.g. our financial forecast) and took months to develop fully.

Sharing knowledge

Sharing knowledge has always been a part of our organization. Most of it was done quite informally through day-to-day discussions and feedback. Moreover, we had been organizing monthly online presentations. Most of them, however, revolved around sharing our technical expertise. In order to broaden our horizons and improve our non-technical skills, we diversified the content that was being presented. For example, there were speeches and panels on topics such as productivity, goal setting, professional networking, personal finances and retirement, purpose of life, investing, or digital privacy. We also introduced biannual workshops that allowed us to raise awareness about potential problems and challenges and discuss possible solutions. In general, the process is relatively slow, and the long-term gains are not yet measurable.

Simplifying company goals

In order to align our efforts and make everyone’s responsibilities more clear, we have been using OKRs. ⁵ However, in the past, our communication around our direction and priorities was not clear enough. For example, in Q1 of 2018 twelve people prepared OKRs, which resulted in 24 distinct objectives followed by 94 key results. It was evident that our company’s actual priorities were not clear to anyone.

During our Q2 planning meeting, we decided to fix this. From our discussion emerged two essential goals. The idea was to align most of what we do with these goals while allowing some room for bottom-up initiatives. Afterwards, everyone proposed their quarterly OKRs with objectives that strongly correlated to both priorities. We had finally defined a common goal.

We also changed how we communicated our progress. For example, during our weekly company-wide meetings, instead of just reporting what was done in different parts of our organization, we always related all efforts to our main goals. The difference is subtle, but there is no individual at the company now who doesn’t know what our priority is despite the fact that numerous activities are happening simultaneously. This clarity makes it much easier for individuals to decide for themselves what to focus on first and how to effectively contribute.

Introducing self-set salaries

In the past, we spent a lot of time on discussions and drafts of a fair and objective promotion and salary system. The idea was to have a clear set of requirements for each level. However, an approach such as this is always based on a set of simplifications. It’s impossible to come up with a solution that takes everything into account. The more subtleties we want to address, the more complex and harder the system becomes to use. Even if we prepared a comprehensive matrix of requirements, the assessment of who met which condition would still be subjective. It is also difficult to balance the importance of different criteria. Moreover, we were afraid of sending the wrong message. We were afraid that we might misplace our team’s focus. They should be contributing to our common goals by developing necessary skills. Instead, they might aim for just what was required.

Having all the downsides in mind, we decided to try something completely different. We delegated the responsibility of setting salaries to each individual at the company. I described the whole process in one of my previous articles. This solution forced the team to learn the art of self-evaluation. They became more aware of the difficulty of performance appraisal and took greater responsibility for their own consequences. On the company level, it not only simplified the process but also exposed all of us to a vast amount of feedback, which was delivered on a regular basis. Ultimately, delegating this responsibility strengthened the engagement of our employees and their feeling of ownership over the company’s success.

Making recruitment our mutual responsibility

For an agency like ours, recruitment is one of core competencies and, often, a priority due to the industry’s high demand for software developers. Previously, our recruitment process was mainly the responsibility of the management. Developers handled the technical part of the interview process, but they weren’t concerned much about the rest. Two changes were especially helpful in improving our procedures and engaging the team.

The first was related to the last stage of the process. Its purpose is to make sure that the candidate fits into our core values and company culture. Originally, we had only one interview at this stage with either myself, Mariusz or Grzegorz. Instead, we introduced 5 to 10 interviews (depending on the position) with different employees. Our developers had a chance to interview their potential coworkers with the expectation that they would focus on their non-technical skills. Moreover, when we know beforehand which team the candidate is going to be assigned, the team leader for this team is solely responsible for making the hiring decision. The process may look expensive and time-consuming, but alternatively so is making a bad hire.

The second important improvement was providing the team with a much better context about the outcomes of our recruitment efforts. In order to do so, we organized a workshop. The goal was to explain how recruitment affects our organization. Our discussions and presentations included:

• how our recruitment pipeline works
• past failures and their consequences for the team and our customers
• the importance of an accurate assessment of candidates as well as likelihood
• different criteria and requirements we should keep in mind during interviews

In a relatively short time, we experienced numerous positive results from both advancements. The engagement of the team increased significantly. They were not only more eager to act as interviewers but also improved the quality and scope of their appraisal. We also delivered more comprehensive feedback to our candidates and surprisingly sped up the entire process.

Feedback workshop, October 2018, Lodz, Poland

The main drivers of change

There were two main drivers of change behind most of our improvements:

1. expanding the context available to our team by being more transparent and developing new tools
2. empowering the team to become more self-sufficient and responsible by delegating control and authority

In my opinion, it would have been impossible to create a similar environment without a certain mindset among the top management. If Mariusz, Grzegorz or I had a hard time being more transparent or handing over control of different aspects of the company, we would still be trying to run the show and limiting the potential of the entire organization. The prerequisite of a bigger change was a shift in our own thinking and approach. I’m emphasizing this point not to show off our brilliance. On the contrary, our poor leadership significantly contributed to the substandard state of the company in the past. We had to grow first to allow our employees to grow.

In my previous article, I described the importance of transparency together with the biggest fears around it. I perceive transparency as key to better context building. Without transparency, it becomes difficult to expect high-quality decisions and increased responsibility among the team members. When it comes to delegating control and authority, I would like to quote Steven B. Sample, the author of The Contrarian’s Guide to Leadership:

This is one of the conundrums that prevent most people from becoming effective leaders: they believe (erroneously, as it turns out) that if they have the authority to decide a certain issue, and if in the end they must take personal responsibility for the decision (especially if it proves to be a mistake), then they themselves must personally make the decision. It’s simply inconceivable to the average person that he should under any circumstances allow a subordinate to make an erroneous decision for which he (the leader) will be held ultimately responsible. But that is in fact the very essence of major-league leadership.

Conclusion

It’s been around two years since the peak of our problems and our first attempts to address them. We introduced many small and large improvements that collectively compounded to create a significant shift in how our organization works. The way in which the team progressed as a whole stands out the most.

In relation to the numerous problems that I described at the beginning of this article, I am happy to report that we managed to move the needle on most of them. Because of a substantial change in how we set expectations and educated the team, we have a much better environment today that is more suitable for shaping versatile individuals. Moreover, openness, honesty and a willingness to receive help have contributed to engaging our team and spreading responsibility among its members. There are still dedicated people overlooking various parts of our organization, but they also are more willing to ask for help and receive unsolicited assistance from others.

When it comes to creating a unique value proposition for developers, we can still improve. We are somewhat differentiated from others now, but our offer is still not strong enough to attract our top target group. Candidates deliberately looking for an environment like ours are still rare. Most of the applicants have a hard time grasping our company’s culture. It’s not only difficult for us to explain but also quite contrarian to their previous experiences.

Similar to many other agencies, we are still in search of more predictable revenue streams. We managed to stabilize our positive cash flow and “buy” ourselves some time to identify a new strategic path for the future. One of the most interesting lessons, that we learned during this difficult period, related to the way in which our team reacted. Their attitude reflected a strong belief in themselves and their own abilities and a willingness to make the organization successful. I am very proud to work with this team and deeply admire their spirit and tenacity.

I am curious about your approach to context building and delegation of authority. How you and your company have experimented, and what solutions have you tried? What has been successful, and what have been the pitfalls? Feel free to share any questions and comments on Twitter or via email.

Notes