The advantages of a large orginization
A large organization is like a substantial vessel. Such a vessel remains stable when encountering significant waves. A large organization offers its employees a vast array of opportunities and resources, enabling them to continually enhance their skills and knowledge.
Moreover, a large organization consistently captures and adapts to market trends and technological advancements. This proactive approach ensures that the organization remains competitive and innovative.
Additionally, a large organization possesses extensive global resources and can manage these resources effectively. This global reach and resource management ability allow the organization to operate efficiently across different regions and markets.
The advantages might also change to be the problems that cause additional costs when facing some competitors.
For example, the cooperation of engineers from different locations, communication, and development dependency will cause additional time and cost in release delivery Compared to competitors with all developers at the same location.
It is not about which way is good or bad. It is about how some advantages can become disadvantages when faced with competitors nowadays.
Some suggestions for large orginization to speedup
I will outline some points from a working level that directly relate to the slowness of daily work in large organizations. First, I want to make it clear that slow is not always bad and fast is not always good because sometimes we believe we are saving money by developing quickly, but the money saved will be used elsewhere.
The communication
Employee software skills are improved through training because communication is so important in our daily work. We still have communication problems at work even though we speak the same language. This is due to the reality that everyone has a different background. There is a knowledge or information gap between individuals. Therefore, we should be careful to provide appropriate background and context before speaking to somebody about topic.
For instance, when the display component and lifecycle component engineers discuss a system power management issue. The lifecycle component engineers don’t have the same understanding of display topics as display component engineers. The display component engineers don’t have deep understanding about the system lifecycle component design. So, additional time must be spent during the communication to ensure each side has the correct communication.
The problem here is not about how to improve communication. It is about related engineers who must be aware and willing to close the information gap. It is additional effort for component A to understand the design of component B. The engineers from component A can say: “I don’t need to understand component B. Sorry, I did the implementation which followed the customer requirements.”\
Is it make sense ? YES. There is no any issue for a engineer to say that. And it looks like only architecture is required to understand the design from different components.
That’s because engineers normally take time to understand one important thing from the work: Ability growth is based on knowledge and skill growth. Problem-solving skill is the most important measurement of an engineer’s capability. So, this should motivate engineers to improve the information gap and daily communication to benefit project executions.
The issue description is an additional example. How can a problem be fully explained so that others know exactly what happened? Ideally, The writer must make the description seem like a movie to give the reader a perspective. The writer should also consider whether readers can get enough information from the text by reading it. This can be improved in two directions. The writer should make sure the description is as clear as possible and doesn’t miss any necessary information. The reader should also be aware that clear feedback should be given to the writer about what information is missing or what he needs from the writer. E-mail discussions shall be stopped if the issue is still unclear after three e-mail communications. A conference call is necessary to clarify the unclear parts of the topics or issues.
“NO RESOURCE”
“We can not deliver this feature in 2 weeks because we don’t currently have the resources. We don’t have an ETA for this feature release. Because we are busy for xxx implement. Or becasue we current don’t have resource”
What a simple reason !! But it shall not be accepted !!
Resource is always an issue because project need to control the cost. Using fewer resources to reach the same goal is always the expectation. So, an engineer’s ability to finish work under stress or in poor conditions is an important measurement metric. Here, we are not discussing suppressing the work from 2 weeks to 1 week. Here is talking about the ability of a team to deliver the work w/o “no resource” reasons.
Aggressive planning
The scrum process is a good agile method for the team to define a goal and break down the steps to reach it. Then, they make a development plan for each step. This process pushes the team members to think about what they need to prepare for every step and to identify gaps and dependencies before starting the work. The goal is to ensure the deliverability of a single team. If all component teams can achieve the goal of deliverability, then the complete project’s deliverability can also be guaranteed.
To ensure the team can 100% finish the work, the planning normally only plans 50%—60% of the team’s capacity. Because the highest priority is the deliverability of the planned tasks, there is always a gap between the plan making and plan execution. So, a plan with a team’s 100% capacity is not suggested.
But I have different ideas. A better way is to plan the work, which is % 120 of the team’s capacity, with %20 being the tasks we can accept for the team not being able to finish them. The team shall try their best to achieve the %120 goal. Those %20 are the highlights of the team’s performance in case they can finish them. The team needs to be encouraged to finish more work, and this is connected to the performance measurement.
So, if we define %120, we can get %100 ~ %120. If we only define %60 work, we can only get %60 output.
Efforts estimation and competence buildup
When a team plans features, team members estimate how long they need to spend on each step. Different engineers have different capabilities, so they take different amounts of time to finish the same task. It is understandable that experienced engineers take less time than fresh engineers. But what are reasonable efforts to be selected finally?
First, ALL team members must correctly understand what needs to be implemented. Second, every team must have a technical expert to ensure reasonable efforts are selected. Learning time is also expensive. If a team member is very clear about how to implement the task, we shall select this engineer to take it for faster delivery. However, an experienced engineer can not take on all the tasks. We can only let this experienced engineer take on some of the tasks.
How do we make the team deliver faster? More experienced engineers mean more faster. However, this is not possible because of the cost consideration and the reality of the availability of professional engineers.
Learning time costs can not be avoided. So, avoiding unnecessary learning time is the way to improve the team’s ability to deliver fast. The team shall be aware of how to do knowledge management. The knowledge management shall include a knowledge matrix about the necessary knowledge required about this team’s responsibility, except the background knowledge.
The team shall also track individual capability. What are the expectations of each team member? What’s the current level, and where is the gap? Identifying the gap and accurately improving knowledge and skills is important for learning efficiency. Team members’ knowledge and skill growth can link to individual performance, which motivates personal improvement.
The engineers should also be aware that they should spend additional time studying independently and not wait for a learning task from a project. It is about individual competence and elevating personal value.
Conclusion
Personal growth is always the most important thing. Personal competitiveness will finally reflect on the company’s competitiveness.
The company’s competitiveness will finally return to individuals with more opportunities for personal growth.
TBC.. MAYBE…
