TL;DR Many engineering organizations postpone their most ambitious plans due to cost constraints for so long that they start to believe that it's only money that limits their capabilities. When they eventually get funds, they learn (in a painful way) that scaling up in an efficient manner is not really a matter of funding (actually it's one of LESS meaningful factors) -> software engineering is a very fragile process w/o a simple formula to define Ability to Deliver (Execute) in a period of time. Instead, there are several important components with lower than linear positive impact (above some reasonable treshold) & farly higher than exponential negative impact (below the bottom limit of sensibility range).
Some time ago I've committed a blog post about (meta-)trait I find the absolutely most importants in engineer I keep working with: Ability to Execute (ATE, AtE, A2E).
What I didn't write about is the (I assumed: obvious) fact that this characteristic is not specific to individuals only. You can quite easily maps it onto larger & more complex units -> teams or even whole organizations. I'm not really inventing anything new here: some key remarks (e.g. about delivery capabilities NOT scaling linearly with headcount) already stated in famous "The Mythical Man-Month", over 20 years ago.
A2E ain't about business value
In short words, I define A2E on the level of the company as an ability to successfully deliver a software-based service (or a change within it):
- in a way that meets the business expectations (these do not have to be valid, there's nothing about business value here!)
- with a sufficient, fully aware control of the risks
- with a reasonable level of waste (on communication, delivery pipeline stages, re-work, etc.)
- in a way that contributes positively to the "health" of org's engineering unit & its culture
In the end you can measure A2E only with actual value delivered - finished, approved, fully deployed product. Obviously, with a sufficient level of experience & knowledge, you can tell a lot based on the observations of delivery process itself. Why so? Keep in mind that A2E is NOT about real effectiveness, but despised "engineering" efficiency. However - this is the efficiency of whole delivery "pipeline", not individuals' performance measured with local metrics (lines comitted into repo per day ;P).
So A2E is all about good engineering, even if the product is (in the end) devoid of any reasonable use. By 'good engineering' I don't mean just turning atomic user stories into code: it's about all activities that are crucial to delivery hiqh quality software-based services, incl. design, mature CI approach, QA, operations, etc.
This is REAL shit
Why do I distinguish this term (& emphasize its importance) so much? Because majority of 13+ years I've spent as a high-profile software consultant was not about delivering projects with our (my employer's) teams - in fact the typical scenario was to infuse (with our guys) clients' teams, because their A2E was not sufficient (to achieve something their organization wanted). We were the minority (in terms of headcount), but our role was to "make the difference" - not necessarily (I'd even say - rarily) as the best developers in the teams.
This makes me truly appreciate the concept of A2E & evaluate teams / unit / companites in context of their A2E. And today I can't help being truly amazed of how many people (frequently: in a very senior positions) still do not get the idea of what REALLY contributes to engineering unit's productivity ...
"Top" 10 misconceptions about A2E
The most typical mistakes are about:
- headcount - "the more the better! we have money, we can build 2nd Google in 3 months now!"; in fact -> more people obviously isn't necessarily a bad thing, the only (but HUGE) problem with increasing the number of contributors is that it insanely boosts the impact multiplier for all other problems / inefficiences -> e.g. in areas of communication, dependency mgmt, leadership, etc. Big team is the worst fuck-up catalyst ever.
- ignoring the ToC (Theory of Constraints) - your delivery pipeline is as efficient as its worst global bottleneck lets it to be; local improvements & optimisations are meaningless, they are just the waste of time, effort, positive energy & people's morale
- inability to learn from mistakes - if you've fucked up doing something 5 times in a row & you didn't draw any conclusions (based on actual, tangible facts; guesswork doesn't apply ;P), what makes you think you'll succeed this time? Especially if the stuff you'd like to do now is 3 times bigger? ;P
- teams' balance - team's balance ain't only about efficiency of particular delivery "phases", but it's also about the internal balance -> there have to be credible leaders (formal or informal, full spectrum or competency-specific) on each level of contributing, there have to be a healthy setup of competencies, temperaments, goals (individual ones as well ...), etc. And there has to be time to work out this balance -> bunch of freshly recruited, "random" people do not really make a team
- feedback - another crucial point on the list; each quantum of work needs getting the relevant feedback, otherwise people will stop caring at some point OR they'll switch their priorities to what seems the most relevant to them (so they will "provide the feedback themselves") - this is a freaking natural reaction for humans! Leaving engineers play with something for months w/o integrating or showing anything to the stakeholders just because "they are highest paid professionals" or "it's a waste to check this out until it's fully ready" is one of the worst categories of waste
- minimizing dependencies - optimized communication paths (avoiding "invisible walls"), clear success criteria that do not depend on factors out of our control, no ignored impediments ("we just know it's here, we pretend not to notice that") -> screwing up in this area removes ownership from people, pushes them towards "victimship" or (maybe even worse) creates the effect of "social loafing" (I've stoled this term from latest book of Adam Tornhill) - when people see that the (end-) effect of their effort is much less than could be expected (based on common norms) or they even can't find the correspondence between their work & final goal, they stop giving any f%ck.
- mature framework of work - not a bunch of outdated policies, but really applicable, everyday stuff (unequivocal & understandable for everyone, known & approved by everyone): DoD, levels of autonomy (yes, not responsibilities but autonomy), clear (non-overlapping) accountabilities for roles, mechanisms to keep continuous alignment on all efforts (coordination); no "dead" rules that can't be validated / monitored & lack even basic justification
- experience & knowledge - just because someone is in the organization for 10+ years doesn't mean (s)he can deliver (/lead delivery of) something he had barely any knowledge about. Experience in comparable, sufficiently similar area is necessary - this is engineering after all! Not only to actual know what to do next, but also to provide the overall credibility in the eyes of people one leads. By knowledge I don't mean the tech-specific one only -> actually this is most likely the easiest thing to provide (as long as you have funds granted, ofc).
- operational transparency - quite likely the most crucial one on this list -> in this context 'transparency' is all about always knowing where you are (in terms of progress) & how does it correspond to the whole endeavor. What does it mean? Without contextual awareness, you can't manage the delivery & there's no contextual awareness without honestly knowing what's the state of delivery: what do we have already done, what's next to be done, is it really the highest priority, etc. Not mentioning the effect of lack of visible sense of progress on people's motivation ... These are freaking basics & it's just stunning how many managers do not get that.
- engagement - the most dumb (& one of the most frequent, in the same time) sin is assuming that "fixing engagement" will in consequence fix all the other issues, while in fact ... it's completely the other way around! Engagement is the EFFECT of how work environment operates, how people fit in, how well it's aligned with their goals/ambitions/expectations ...
Error. Progress not found.
I've seen factories of few hundred developers which were delivering close to nothing (while keeping everyone super-busy whole days for months) & small, focused workshops (teams) that were making wonders in just weeks. Yes, software engineering is not really a forgiving type of business - you may have just 1 inefficiency in your "garage", but if it's the "wrong one", it still may cut your engineering unit's hamstrings (if not handled properly). And against some naive beliefs, progress can be LITERALLY nothing, even while everyone is running around like crazy, 8-22 five days per week + weekends. I've actually already written a blog post on that very topic - still relevant today.
