In small to medium-sized businesses (SMBs), the success of a software development project often hinges on the clarity of roles and responsibilities within the team. Unlike larger organizations with extensive resources and well-defined structures, SMBs must be particularly vigilant in avoiding ambiguity and confusion that can lead to inefficiencies and conflicts.
If only two people are doing the same work or are stepping on each other’s toes, that’s already an expense in time and money that can set you back considerably (remember, if you’re a growing company, problems tend to stack on each other).
One of the biggest challenges SMBs face is ensuring that every team member understands their specific role and what is expected of them. Without clear definitions, tasks can overlap, accountability can wane, and productivity can suffer.
However, it’s not just about defining roles—it’s also about setting clear expectations. When team members know exactly what is expected of them, they are more likely to take ownership of their tasks, deliver high-quality work, and contribute to the overall success of the project and the company. Clear expectations foster a sense of responsibility and drive performance, leading to more efficient and effective development processes.
When it comes to this part, people involved in defining the roles and expectations usually make a big mistake. Instead of properly defining team members’ responsibilities, they limit their reach. Instead of giving people clear guidance about what their main focus should be, companies tend to put them inside small boxes, drawing borders around them and instructing them to stay within their designated communication and operation domains.
If done well, clearly defined expectations and responsibilities enable radical freedom of communication and operation for all employees, regardless of their position in the hierarchy. This enables free flow and access to the best information to make informed and smart decisions.
Figure 2.0.1 depicts the most common setup in SMBs, where instead of improving the flow with clearly defined expectations and responsibilities, communication barriers and procedures are in place, and information flow is limited.
Figure 2.0.2 displays free-flowing roles that are unrestricted in their area of operation. With clearly defined expectations and responsibilities, you don’t need to introduce any processes to guide communication or set constraints. If everyone is clear on what to do and focus on, and if that is defined with the company’s interest in mind, working towards the same goal comes logically.
By having CDER, you can ensure that your team operates smoothly, with everyone aligned and working towards common goals without imposing limitations that will hurt both the employees and the company.
When determining the approach to team setup and processes, it’s crucial to avoid adopting rules that are too large for your current size. Many businesses overestimate the need for scale and adopt processes that are over-engineered and slow for their size. Most available material is written with large organizations in mind, which can be misleading for smaller companies.
This focus on large-scale solutions is logical; big companies have the resources to document and share their processes extensively. However, as a small to medium-sized business, your resources are better spent on building your product and expanding your client base.
Introduce new processes, rules, and flows only when things start breaking apart without them. Avoid adding processes in anticipation of problems; instead, implement them as a response to actual needs. Each new rule or step is a commitment of resources that will accumulate over time, multiplying as your team grows. In many cases, having no processes is better than having too many.
Companies that over-engineer their processes often have underlying issues related to role and responsibility definitions or communication problems. In contrast, teams of smart, autonomous, and proactive people usually thrive with minimal or no processes. Building and growing such a team is challenging but achievable with the right approach.
The Concept of Minimally Defined Development Processes
Minimally Defined Development Processes (MDDP) emphasize simplicity and effectiveness, ensuring that your team can work efficiently without being bogged down by unnecessary complexity. Here’s how to implement this approach:
Start Small and Iterate: Begin with the minimum viable process—a set of essential steps that allow you to deliver a functional product. Test this process in real-world conditions and iterate based on feedback. This approach helps avoid overengineering and ensures that your process evolves organically as your needs change.
Focus on Value: Prioritize tasks and features that deliver the most value to your customers. Regularly reassess what’s essential and what can be trimmed. This focus keeps your development lean and directed towards what matters most.
Empower Your Team: Encourage your team to identify inefficiencies and suggest improvements. Empowered teams are more engaged and better positioned to create effective, lean processes. Trust their expertise and involve them in shaping the development workflow.
Implement Just-In-Time Processes: Introduce processes just in time, rather than just in case. This means adding steps or rules only when a clear need arises. This approach keeps your workflow lean and responsive.
Benefits of Minimally Defined Processes
By adopting minimally defined processes, your team can benefit in several ways:
Increased Agility: With fewer unnecessary steps, your team can move faster and adapt more easily to changes. This agility is crucial for responding to market demands and customer feedback promptly.
Improved Focus: By cutting out non-essential activities, your team can concentrate on what truly matters—delivering high-quality software that meets customer needs.
Enhanced Morale: Teams burdened by cumbersome processes can become frustrated and disengaged. Minimally defined processes foster a more satisfying work environment, where team members feel their contributions are valued and impactful.
Better Resource Allocation: Simplified processes mean fewer resources are wasted on managing complexity. This allows you to allocate more time and effort towards innovation and product development.
Heuristics
Does this process help us eliminate waste in our development cycle?
Is quality being built into our product from the start?
Are we fostering a culture of continuous learning and improvement?
Is this process flexible enough to adapt to late-stage information and changing requirements?
Are we able to deliver incremental value quickly and iteratively?
Does this process respect and empower our team members?
How does this process optimize the entire value stream, rather than just individual components?
Conclusion
For SMBs, adopting minimally defined development processes is a strategic advantage. It helps avoid the pitfalls of over-engineering, keeps your team agile, and ensures that your resources are focused on delivering value to your customers. By starting small, prioritizing value, empowering your team, and implementing just-in-time processes, you can create an efficient and effective development workflow tailored to your business’s unique needs.
You have the company, the vision, the product, and the plan to improve it and make it more feature rich. You also have the stakeholders, who are anxious to see those new features delivered. If you’re responsible for that delivery, now you also have a problem!
You don’t want to overpromise, nor do you want to underpromise. One thing is sure: you must promise something; commitment is not optional.
This is where the problem starts. If you overpromise, you’ll probably miss every deadline, putting immense pressure on the people working on the deliverables. If you underpromise, you’re not realizing the full potential of your product teams, and you’re wasting resources.
So, you do the sensible thing. You tell the product teams to plan their sprint (or any other unit you use to measure an interval of work), committing only to the number of deliverables they are highly confident of guaranteeing. Teams will do their due diligence and ensure the number of deliverables is optimal, with maximum utilization of the team’s resources and a “quality first” mindset.
And they lived happily ever after—the end.
Well… not exactly. Unfortunately, the reality is a bit different. The story above is just one side of the medal. The other side is how you run the company and evaluate the performance of the teams and their members.
To assess performance, you need some metrics. And this is where it can get tricky. Metrics are problematic because if you’re not careful about how you set those, you can end up incentivizing rather unhealthy and unwanted behavior.
Let me use a simple example from our story at the beginning of this post to discuss “deliverables.”
Let’s say you have two teams, a blue and a yellow team. You decided to introduce a metric that shows whether the teams responsible can achieve a pre-agreed number of deliveries per sprint. As delivery is a pretty ambiguous term, you agreed to talk to both teams before each sprint, discuss the complexity of the deliverables, and see if you can decide on how many deliverables they can commit to.
After ten sprints, you look at the metrics. A blue team committed each sprint to four deliverables, achieving their goal every sprint. On the other hand, the yellow team committed each sprint to three deliverables, but they failed to meet their goal three times out of ten.
Your metrics tell you that the blue team should be rewarded, and the yellow team should have their performance evaluated. I’m oversimplifying this situation, and any sensible manager wouldn’t reward or reprimand the team based on one metric. Still, organizations often have many loosely defined metrics, which can all lead to questionable actions.
While it might be true that the blue team overperforms the yellow team, you can’t be sure. The metric used in the example leaves a lot of possibilities (and some questionable behavior) open. Here are some examples:
The blue team is better at overselling the complexity of the deliverables, lowering the actual output they’ll commit to. The yellow team might be better at sales but not necessarily at delivery.
The blue team decides to overlook quality (testing, covering edge cases, cleaning technical debt, etc.), optimizing for shipping as many features as possible but endangering the product long-term.
The blue team marks some product requirements as not feasible during the discovery/refinement sessions to avoid dealing with potentially uncertain work (albeit possibly yielding high rewards for the company)
The yellow team could’ve possibly delivered multiples of what the yellow team achieved, always trying to push themselves more each sprint. They optimized for value and set ambitious goals to advance the product further.
My examples describe the blue team as toxic, and this might be extreme, but it illustrates the point pretty well. Anecdotally, working in several toxic environments in the past, I witnessed this behavior first-hand.
Even though it’s rarely the intention of the person responsible, some metrics they introduce to their teams can be EVIL! This is how I define an evil metric.
An “EVIL METRIC” is a performance metric that, due to its design or the context in which it is applied, can lead to behaviors contrary to the best interests of the team, product, or company.
It promotes short-term gains at the expense of long-term success, quality, and team morale. It can lead to toxic behaviors such as gaming the system, overselling, underdelivering, neglecting quality, and avoiding challenging but potentially rewarding work.
How to avoid implementing evil metrics?
Here are some questions you can ask yourself when you’re thinking about the metrics you want to use to assess the performance of your team(s):
What behaviors will this metric incentivize? Are there any negative behaviors it might inadvertently promote?
Does this metric favor quantity over quality, or does it balance both?
Is the metric understandable, and can team members see how their actions directly influence it?
How easy is it to game or manipulate this metric? What safeguards are in place to prevent this?
Does the metric fairly evaluate all team members, considering the diversity of roles and tasks?
How will this metric be used in conjunction with rewards and recognition? Will it encourage teamwork and collaboration or foster unhealthy competition?
Final thoughts
Ensure the metrics you use promote fair play and are not prone to manipulation. Discuss the metrics with the team and gather feedback. You should never use metrics that are not transparent to those who will be evaluated based on them.
Reporting on progress and communicating with stakeholders don’t have to overlap with evaluating your team’s productivity. There is a balance, but it requires a lot of work to establish. All the good things do! Happy metric setting, and don’t be evil!
