Introduction
The question that frequently pops up during discussion with colleagues and friends is:
“What’s next?”
The question triggers a debate with very subjective answers which are evolving over time. Three years before, the answers included MS, MBA and startup. I used to work for a unicorn and I decided to join a startup to:
- Learn about building a company
- Apply my knowledge and skills that I had acquired
- Explore the limit of my abilities
As the excitement of the new year sets in, this article is more like a note to self about how I perceive engineering as an organisation.
Engineering as an “org”
Like a company has a mission and vision, which guides the company’s action and strategy; similarly engineering as an organisation within the company should have a vision. It goes unsaid that one of the most important expectations from the engineering org is business continuity.
The term business continuity can be broken down into the following major components:
- Uptime should be 100%
- New features are incorporated
- Bugs are solved
- Latencies are within reasonable limits
Now, engineering org should have a mission and vision that could be derived from something that threatens the business continuity. For example, if the problem is attrition, which might lead to decrease in count of new features incorporated. Then the mission could be to hire and mentor talents. Similarly, if there are high count of bugs, the mission could be to do exhaustive testing with a long term vision of having more than 95 percent unit test code coverage.
Process
Any established company has set processes for the business continuity. Startups on the other hand are limited by the resources that they have. There is always a shortage of manpower. Setting up new processes with a startup can also be perceived as a nuisance as it might lead to unnecessary bureaucracy. This is detrimental for a startup environment where turnaround time is worshipped metric by non-engineering stakeholders.
In this scenario, the answer to the following question is something to be thought upon:
“How would you set up processes while taking buy-in from every stakeholder?”
One possible way could be proper communication of metric that stakeholders hold dear to them which is improved by setting up process. For example, engineering org decides to have a dedicated engineer to solve production bugs which results in reduction of turnaround time reduction from four days to one day. That’s 75% improvement and should be communicated to operation team about the advantage of having a dedicated on-call.
Refactoring
Refactoring is an exercise that has to be taken up periodically. New features frequently modifies existing flows to accommodate feature requirements. In most cases, unit tests take backseat as startups are always fighting for survival. With “time to market” as one of the important metrics to measure efficiency of engineering org, code is more prone to bugs and break some other existing feature silently. As such, there is a constant need to refactor small parts to control the chaos. Again, convincing all the stakeholders about refactoring could be a tough sale, provided refactoring does not directly lead to any change in measurable metrics. One observation is badly designed or coded module almost always result in regression bug. One way to attribute advantage of regression could be the reduction in the count of regression bugs.
Documentation
Documentation is a key area which is always neglected, both in terms of tech and product. We tried addressing this issue by rigorous tech grooming session where each of the features being developed is presented before the engineering team. The presented tech document usually contains the architecture diagram, class diagram and related notes. Such initiatives have helped in more mature designs because of the involvement of the whole team in developing design. Audience is someone who has worked on the module before, or someone who has solved bug related to the module or someone who makes an intelligent remark which is easy to be missed.
Such open discussions also mature to sharing knowledge about the tech concepts, both trivial and the advanced topic. Another result of discussion is possible points for roadmap when someone in the room asks:
“Isn’t this use case for Golang?”
“Shouldn’t we use some other design pattern?”
Proper documentation in terms of product features is always challenging. Product features are usually code with lot of configurability at different levels and stored in different data stores. With time, many less used flags/features are forgotten and there are always new features which conflict with existing feature.
Mentorship
Mentorship is all about enabling people. Mentorship is not about providing the fast paced solution rather, it is about enabling them to face problems. First step to mentor someone is to make them trust their abilities and making them sync with the feeling that “they belong there”. Subsequently, It’s important to let them challenge themselves by finding solutions on their own. There should be an honest debate about the solution in order to further improve it. There should be necessary freedom as well as close monitoring in order to provide them with nudges to improve.
Did you hear,”Filtering a list to get unique? Why not use set instead?”
Another interesting observation is to ask, “What is a good code?” The keywords in answers will be “fast”, “maintainable”, “extendable”, “modular” and “reusable”. A good way for someone to improve is to make them evaluate their own code with respect to the definition of “good code”. Chances are code is going in the right direction.
Another important aspect of mentoring is to make people aware of the environment. Someone develops a feature. How about asking them following questions:
“What’s the response time?”
“Could you use cache to improve response time?”
“But does using cache increase hardware cost?”
That sort of sums up the 2019 experiences. There are things which could have been better. But I guess it’s okay to make mistakes and learn from them.
Praying for a happy new year for everyone.
If you liked this article and would like one such blog to land in your inbox every week, consider subscribing to our newsletter: https://skillcaptain.substack.com
Leave a Reply