Scaling a Saas Company part 3 of 3
Popular concepts in a growing saas company
In the previous post we talked about the organization, the business problem it solves and the system it builds to solve that problem. In the following sections we will comment on some popular concepts often mentioned by leaders in growing saas companies.
Transparency
Transparency is often mentioned as an important aspect, goal or value that companies try to pursue.
Its obvious that if transparency exists, then we can see what is going on, and it’s easier to identify and solve problems. Transparency is very much about communication, if one team doesn’t communicate to the rest of the organization, no one will know what they do and how they are doing it.
Transparency in software companies now a day are often delivered via an iterative process like Scrum or Kanban or what not, in the form of product backlogs and sprint backlogs. Tasks are groomed and estimated, and the work the team plan to do, and what they do are transparent to the rest of the organization.
The place where transparency often is missing is transparency in top management decisions. One such example could be an organization restructure. “Due to these circumstances we have chosen to reorganize the organization in the following way”. Only a superficial reason is given, and the process behind and the reasoning involved is never told in detail. This makes it very difficult to access whether alternative ways of doing the reorganization could have been more optimal to the company. Has valuable information been left out or overlooked? It prevents the employees from helping management to make the right well educated decisions. It prevents the discussion, that could have brought insight to the process. Well maybe you want to avoid that discussion, discussions are time consuming. It’s a balance. But in modern management philosophy its common advice that management should listen to its employees.
“Listen to your employees”
Empowerment
Another modern management mantra is that employees and teams should be empowered. The intention is quite clear, in stead of top down micromanagement, the employee and team should act in an autonomous way, so they can make their own impactful decisions, rather than waiting for someone higher up to decide or having to negotiate with other teams on a decision. Empowerment will make the organization more effective, because the decision process is optimized.
However, in reality, this often breaks down. Why? As an individual your tasks might still be given from ‘above’ so the number of tasks you have promised to work on and complete, makes it impossible for you to take a decision on something that should be corrected. You simply don’t have the time to do the work related to change something. Another reason why empowerment doesn’t really work is the case of decisions involving many teams, or coworkers in other teams than the one you are in. Because you cannot force your decision on other teams or individuals, you would have to reach some agreement in cooperation with those teams or those individuals. Since they are also very busy and fully booked with tasks, they might not be inclined to take the time to negotiate a decision and do the work needed to implement the decision.
So how can you make your employees and teams truly empowered?
First of all what are the employees empowered to do? Whatever? Probably not. While this might seem obvious it makes sense to articulate what we mean exactly. The individual or team should always be guided by the company mission and the company values. We are empowered to do things that serve the wellbeing of the organization. We probably have a mandate, ownership or a boundary in which we are empowered.
If the ownership, mandate or boundary is blurry, fussy or not articulated at all, then empowerment breaks down. Take 3 teams as an example. If those teams have well defined ownership and a well-defined boundary in which they operate, then they are also empowered to make decisions within their boundary on subjects where they have ownership.
This becomes difficult if the teams have overlapping boundaries and shared ownership of subjects. If they have contradicting success criteria it gets even worse.
In order to make decisions and act on them for the common good of the organization, they must negotiate and compromise with the other teams. In this case empowerment becomes complicated. All teams are busy, and suddenly one team wants to act on a subject that affects multiple teams. The teams need to coordinate a meeting, but all time might be booked up front. What if the teams do not agree? A lot of time can be wasted. If this becomes the norm, its an indication of nonoptimal team and responsibility boundaries.
Non-autonomous teams due to poorly chosen team boundaries with no obvious ownership can cripple empowerment.
The concept of empowerment is appealing, but in practice it can be hard or nearly impossible to bring an idea from the state of being just an idea to become a decision and further to be implemented. Specially if its a major change that involves cross team communication, and involves actions from many different individuals to succeed.
Silos
Silo is the new curse word. Silos are something to avoid, and with good reason. Handing over work from one silo to the other has been widely accepted as a source of problems. The horror scenario is several silos working for a long time towards a common goal with out communicating, they end up in totally different places — Or one silo being dependent of work from another silo, are blocked by the lack of progress from the other silo, or even worse, once one silo delivers, its not what the other silo expected. We can always find examples of projects going wrong. That doesn’t necessarily prove that the methodology or the strategy was wrong, maybe its was just poorly executed. But we all pretty much know what it is we try to avoid. Poor solutions, Miscommunication, misunderstanding, rework, queues, and waste.
One remedy against silos is apparently a practice of splitting up teams and restructuring teams on a regular basis, this was at least an argument I faced in a start up company. By blending the cards and mixing people in new team constellations, knowledge is spread, and silos are avoided.
While this makes sense its not without downsides. There are other important mechanisms in play when forming teams.
1) Social fit. Can the members work together, do they respect and trust each other?
2) Skills and expertise. The skills in the team must match the tasks given to the team.
3) Motivation. The team members should be motivated by what they are working with. Individuals has dreams and ambitions, by helping to fulfill those ambitions you release a lot of energy, compared to forcing individuals to work with something that doesn’t really interest them.
4) Stability and predictability. Learning to work efficiently together takes time and breaking up a well-functioning team just because you want to spread knowledge is wasteful. Team efficiency are abruptly halted, and new team constellations needs time to get up to speed. We don’t expect a soccer team to perform optimally, instantly if the whole squad has been substituted with new players.
“Leadership: the art of getting someone else to do something you want done because he wants to do it” — Dwight D Eisenhower
If team constellations are not working you might be forced to do something about it and create new teams, but that should not be the normal state of things. Think kaizen and lean, Small improving changes rather than big revolutions. Don’t throw a hand grenade in to the room and then leave it. Rather work with the team and let them improve little by little.
Another thing I have noticed is the confusion between autonomous teams and silos. In the war against silos, people mistakenly say that a well-functioning autonomous team is a silo. The team can work on its own, it works in its own niche and are not involved in debate, and struggles of the other teams, but since its somewhat isolated people think the team has the characteristics of a silo, which is the same as bad.
Autonomous Teams
So, what characterize an autonomous team, and why do we want them? The reason why we seek autonomy was touched upon previously in the part about Empowerment. An autonomous team should be capable of removing obstacles and problems on their own. Think about a factory assembly line with no autonomy. Some place in the line a problem occurs, everything halts, nothing happens, because all the workers waits for some manager or director to come and solve the problem or give an order on what to do. This is the opposite of being autonomous. Teams should be self-driven, capable of making decisions and solving problems by themselves.
The strategic design patterns presented by the Domain Driven Design movement can help here. Remember we touched upon that in the previous section titled ‘the Problem’
Remember one problem domain <-> one bounded context <-> one team
Let’s assume that only one team should work in one bounded context.
If we can map the sub-domains and the bounded contexts in an enterprise, then we will also see what teams we should form. And how those teams are related.
This is important. If we want to optimize, then inter team logistics is important.
What kind of relationship exists between two teams, which team is upstream and which team I downstream. Evans introduces several patterns to describe these team relationships.
For an interesting in debt coverage of the concept of designing socio-technological teams, read the articles written by Nick Tune, they can be found here
Agile
The word agile is about being flexible, being able to respond to change.
An Agile software development process is iteration based. After each iteration a team can reflect and has the chance to adjust direction based on feedback from users using the system. Having the ability to adjust the direction makes sense when dealing with complex problems and systems. It’s very difficult to find the perfect solution up front for such problems, we need to learn.
Luckily an agile trial and error approach is doable in the software industry, its relatively easy to change bits and bytes. After all we do not pour concrete. Before saas and Continuous Integration and Continuous Delivery a high frequency iteration would have been expensive or impossible. New versions of software were a yearly event, not weekly. CD’s had to be distributed, or even floppy disks or what not. Making a Release of some software was really expensive and time consuming compared with what we can do today.
However, it’s still not free at least in many organizations. Problems like long build queues, failing servers, net work problems, Hosting center problems, DLL hell, package hell or nowadays microservices hell, slows down teams.
The point here is that a fast, agile iterative development cycle requires a well running, well lubricated machine. This machine also must be scaled according to the ambitions of the organization. This often involves a lot of skills and learning for the engineering teams. This is sadly often neglected, since the rest of the company doesn’t understand the complexity or are not interested in the intricate details.
Alistair Cockburn talks about this in recent articles revolving around the title “The Heart of Agile”,
The heart of agile are represented by 4 verbs
Collaborate -> Deliver -> Reflect -> Improve
This becomes an iterative learning and improvement process.
I often see that Reflect and Improve gets skipped. We need to get s… done. So, we work hard but not smart. Look here if you want to read more about the heart of agile
What is often forgotten is that the first software design delivered is often not optimal or perfect. Simply because building software and understanding the problem domain is a learning process. Martin Fowler is quoted for putting it like this.
[…] while you’re programming, you are learning. It’s often the case that it can take a year of programming on a project before you understand what the best design approach should have been. […] — Martin Fowler
When software is not designed in an optimal way or it has not been refined to comply with code guidelines in a team, maybe because the team was in a hurry, we say that we introduce technical debt. Its like taking a loan in a bank. It can be a good choice, but at some time you have to pay back. And the total price will be greater than the price for paying without the loan. Look here for a good article on technical debt.
We hear that we should deliver mvp’s (Minimal viable products), so we first make it work, then we make it better. This makes sense when you want to get rapid feedback from users. Does this design work for you? Does this software solve your problem?
In order to get rapid feedback introducing technical debt can make sense. Maybe the solution work when only few users use it simultaneously. Maybe it’s not perfectly implemented, but its good enough to capture the feedback from the user. The Debt however has to be paid back, by rewriting or refactoring the implementation.
This second part, ‘making it better’ is sadly often forgotten or neglected. Instead the next feature gets added on top of the software, rather than making the existing functionalities better and iconic instead of minimal viable. While every sane person can understand that not paying your interests on a loan will lead to even bigger interest to pay and eventually will lead to bankruptcy, the same kind of reasoning seems to evaporate when it comes to technical debt in a software company. Maybe because its out of sight, then its also out of mind. In reality it can be compared to the US national debt. Or maybe its comparable to our global human environmental debt to the blue planet. Its just a reality we often don’t like to think about or deal with.
Look here for an interesting in debt coverage of this subject
Look here for a sad but, fascinating view of the US national debt growing.
Common sense.
We are coming to the end of this series of posts. Let’s recap.
· Be authentic,
· Listen to your employees,
· Remove the biggest blockers first,
· Don’t follow streamlined and popularized business process blindly. Use common sense.
· Its not enough to introduce new processes, the practices of the process has to be learned and practiced in order to make a tangible difference in the everyday work life of the employee.
· Consider the advice given by the Strategic patterns of domain driven design when designing teams and systems.
· Make sure you take the time to get aligned, better sooner than later.
· Think and communicate in events happening in the problem domain and secondly in the system.
