Ownership and Accountability — A Software Engineer’s Handbook
The last decade saw a paradigm shift in the way software is built. We shifted from a ‘Go Slow but Go Well’ to ‘Fail Fast and Evolve’ strategy. In the wave of those changes, many start-ups have emerged and perished at the blink of the eye.
However, if you notice, among the start-ups that have stayed and are thriving there are a few simple things in common:
They had a strong vision and sense of direction to navigate over a period of time and market requirements.
They are very customer-centric.
They set a very strong value system to live by.
But how do you keep these 3 pillars aligned? The answer lies in ownership and accountability at all levels within the organization. However, I would narrow down my opinions from an engineer’s standpoint.
What is Ownership?
In a very narrow sense, ownership is about responsibilities and duties that an individual performs to achieve the overall organizational objectives. But from a broad sense and an engineer’s standpoint, it involves everything that you can do over and above your regular duties to establish trust and confidence that can resonate across the board and impact bottom-line.
What is Accountability?
Well, that’s very simple for an engineer, when the dirt hits the fan — accept, stay, and then clean, irrespective of the consequences that lie ahead.
If you can fix a production bug at 3.00 AM in the morning without anyone noticing, and still come back the next morning with the same zeal you had the previous day, then you are almost there. That’s accountability alright!
Why Ownership and Accountability Matters for an Engineer?
Simply put, it matters because of it ensures the lateral growth and development. You not only have to think for yourself but also for the team, stakeholders, organization, and its customers. Ownership and accountability makes you ready to start as a Founder, Entrepreneur and Leader who can propel and drive decisions. It keeps you future-ready.
With all said and done, there is still no framework that can be used to define ownership and accountability. Stating anything around this subject would only confine it to a small box. However, in my journey or transition from an engineer to a manager, I have come across a few bullet points that add a lot of weight to this subject. So without further adieu let’s look at a few of them.
1. Look at outcomes — Not Features
Once you look beyond features, you look at the stakeholders and then maybe the customers along with the value addition to their life. A small feature goes a long way. It is this vision that gives an engineer a “Sense of Accomplishment”. And there is no bigger victory than these sort of accomplishments.
2. Strive for Quality
Quality is not just about fewer bugs, it is also the experience that you bring on the table to your peers and stakeholders.
For a Developer, it is about code hygiene and the best code that needs no documentation. It is a craft, an engineer would know only if they have seen more. Therefore, invest time in reading codes that are better. Follow conventions and set a few that favors everyone.
For a Quality Engineer, it is about ruthlessly trying to break the software. And by all means, being a firewall between the developer’s ignorance and customer’s experience.
3. Build for Failure
Invest time and money in building systems that can scale well horizontally and vertically. Get it reviewed and critiqued by your peers and SMEs alike. Keep your ego aside, if there is a potential for failure let it fail right now, on the bloody whiteboard.
If all goes well with the design, incrementally test your software with stress 2x,5x or 10x than what is anticipated. Find out where it can break and communicate it to the stakeholder. It is very important that the limits, constraints and expectations are communicated. Don’t be shy to put profilers and other tools that reveal more about your code.
Establish trust and rapport with the operations/SRE/DevOps team. Keep them posted on Capacity planning. Inform them about the day or time when you expect to see an organic load or spike in traffic. Also remember these are the people who keep a close eye on your systems while you are asleep. Empathize, respect and acknowledge them for the same.
4. Measure and Monitor
Businesses these days are very stringent about commitments. Most B2Bs expect a 99.95% SLA. Some even go to the point of defining a response time SLA. In case of Advertising RTB a standard 100ms response time is a mandate. Thus, winning and losing now is all about being ‘Available and Fast’. We have seen giants like Amazon who have been ridiculed for outages, do we want to be on the list?
a. Establish KPIs, know what to measure
Find what you need to measure it starts with:
- Resource utilization and consumptions (Cpu, Memory, Storage space, Thread Count, Pool Size, QPS, etc).
- Application KPIs — you must also look at your application KPIs. For example, the number of orders processed, the transactions success ratio, etc. Always discuss with product owners on what they would want to measure before you release a major version.
- Set up budgets around infrastructure and cost keep a close tab on costs, perform the monthly audit to find out if you are exceeding or have the potential to exceed for both, seen and unforeseen reasons.
b. Invest in tools to measure and visualize
Invest in tools that can help you visualize the KPIs- Instana, Graphana or whatever suits your need.
c. Setup Alerts and Escalations
Define Yellow and Red thresholds for your KPIs.
Use a non-intrusive way to notify Yellows e.g Slack channel, Email Notification.
For Reds, setup a more intrusive notification like a Phone call, Paging — use tools like PagerDuty and OpsGenine to set up escalations and resolution policies.
5. Release and Post Release Strategy
Build a concrete release strategy. Most often a bad release strategy could just mean a disaster. Make a note of the components and their order of release. Rehearse the whole thing in a staging environment if you can.
a. Blue-Green Deployments
Imbibe an incremental release philosophy. See if you can release the software to a few audience segments, then collect feedback or see what failed and then improvise and release the same to every other audience segment. The segments could define on the basis of Geography, Usage or even Revenue impact.
b. Rollbacks
Always keep a rollback strategy handy. With today’s build and deployment tools, rollbacks have become a fairly simple deal.
c. Monitoring
Keep an eye on all system KPIs post-release, usually, it may take anywhere from a few hours to a day to ascertain the success of the release.
6. Onboarding and Mentoring
The earlier you onboard a new team member, earlier you get to explore new boundaries and horizons. Invest your time in writing documents that matter. Keep it small and concise.
- Team DNA — The value that the team brings onboard.
- Tech Stack.
- Environments (Staging, Dev, Production).
- Setup, Installation and Deployment Guide.
- Practises, Conventions and Release Guides.
- Most importantly Dos and Dont’s.
7. Question and Communicate
Question every decision, no matter how significant or insignificant. Incidentally, it happens to be one of the DNAs at Sixt.
Do not be hesitant to ask questions to avoid sounding stupid and recite this mantra “Stay Hungry, Stay Foolish”.
Learn to communicate effectively and encourage everyone to do so. Change the narrative based on your audience. In case you are talking to your peers, you are allowed to be more technical in your conversation. A small jargon to impress should not hurt anyone. However, if it is your product or stakeholder, try to change how you express an idea in way it could bring a positive impact and minimize the risks involved.
In conclusion, I would say these are the aspects that would make a software engineer a better individual in the professional journey irrespective of whether you are building stuff or buying a product online, sending drones to explore another planet, etc. Please do leave you insights if any of this has made sense to you. Happy to hear your views on this subject.
