 |
As an engineering leader or an executive at a director level of above, one generally has to be responsible for the delivery of the software with the team in the most effective and efficient manner, making sure the team collaborates, works on the agreed scope as defined with product management, do it with quality and ensure customers are happy with the outcome and the product. Software isn’t produced in a vacuum, there is a use case we are solving for, or a business problem we are solving for.
In general, there are key aspects of the Software development lifecycle that are key in addition to the human factors of transparency, cross team collaboration, understanding and leadership we have to worry about as leaders and we are measured on these factors:
General factors
Scope – what is the scope of the features we are building and did we deliver on the market entry requirements. We have to factor in non functional requirements as well such as availability KPIs, performance, security, observability. These are just as important as the feature itself since if something is not secure, unavailable or unobservable when needed, the feature won’t work.
Time – how long something took to build and how much time we actually have to build it – usually this is broken down in agile terms with Epics and stories and the definition of done or definition of ready are key here. The one dimension that’s also key is what I refer to as cycle time. Cycle time allows us to measure how long something took from the story definition time as it was put in the sprint all the way through design, development, deployment and production. The longer the cycle time, the longer the measure of the feature making it to production.
People and Resources – do we have enough people allocated to the work being done which implies your throughput and how the work is divided given the scope. Collaboration, transparency, quality and understanding between different teams plays a big factor here and as a leader its key to have the right skills allocated to the right motivations of the team in order to work well cross functionally. The value system of engineering plays a key role here and also impacts the quality of the deliverable as well the time it takes to deliver the feature.
Quality – this is the non negotiable factor which stamps the effectiveness of how scope, time, and resources all meld together to produce the quality needed. The dimensions here relate to how solid your designs are, how good your product manager defines the features, the testing aspects (automation and manual), test coverage, performance testing and having a sense of completeness to the best of the ability when the feature is shipped. Quality is generally a non negotiable for solid engineering leaders, as time, scope or resources can always change, however quality needs to be and should remain constant. Engineering leaders are measured on quality first, followed how the team in managed and whether they are a trusted entity in order to consistently build good quality software.
Let’s talk a moment about other factors that relate to the quality and human components which encompass your engineering spend covering CapEx and OpEx.
Capital expenditures (CapEx) are long-term investments in physical assets that are expected to provide benefits over a period of years. Examples include acquiring or upgrading real estate or equipment. CapEx is recorded as an asset on the balance sheet and depreciated over time.
Operating expenses (OpEx) are the day-to-day costs needed to keep a company running, such as rent, salaries, utilities, and marketing. OpEx is recorded in the income statement and has a direct impact on the company’s profit in a given fiscal year.
Engineering leadership in general has to also manage these two factors and when we are dealing with quality one needs to be efficient and the question comes into the build vs buy decisioning, so for example when looking at quality one can look at the intersection of CapEx and quality and decide to hire engineering to test the features, when one can leverage automation to do this. One would not get the quality needed with human manual testing or building automation vs the effective use of software to build and run the tests for you for the following reasons:
Employment of QA engineers to keep up with the change of requirements, updates to the frameworks and ability to always keep up with the upgrades of the frameworks, and change of requirements impacts OpEx and reduces your ability to improve cycle time – you will be in “maintenance mode” maintaining the automation of the tests
Upgrade of underlying frameworks – one will have to keep up with framework updates such as selenium and maintain layers on top in order to expose UI elements which may change over time, thereby reducing your ability to have testing quality coverage, again impacting your OpEx as you may need more people to maintain the “testing frameworks” to be used by your engineering team.
Misunderstood requirements – one of the key areas quality comes into play with features is the ability to understand what changed with product management and engineering and this impacts the cycle time, collaboration and reduces your throughput as an overall engineering team, a KPI that you are measured on an engineering leader.
How AI can help
Since the goal is to have as few issues leaked to production as it is technically possible, the number one value that you can get from AI tool like testRigor is ability to build significantly more automated tests for the same amount of time:
And, finally, improve the process to reduce amount of overhead on rewrite
Summary
In summary, its key to take into account implications of spend, and quality when you’re managing an engineering team and optimize for that so that you can get as much coverage as possible, liberate your team to also focus on non functional requirements, automate your testing for span coverage, and improve your cycle time. Cycle time, the shorter it is, gives you competitive advantage in the marketplace when building software and improves you as a leader. There is also the question of quality and pride of the team as soft factors that allow the team to look back, feel a sense of pride for the quality produced, the customer satisfaction gained, and the reduced reopen rate for defects that result in producing a higher quality product.
