In software development, a phrase that gets used frequently is “code smell” – referring to an “odor” that code has or develops due to poor initial design or inattention to refactoring during continued development or maintenance. Hallmarks of “code smell” include things like copying and pasting blocks of code instead of refactoring into callable functions, classes that have or develop multiple responsibilities, overly broad interfaces, and so on.
I think engineering departments can have smell too. Hallmarks of engineering smell include:
- teams that develop processes, tools and frameworks with no expectation of coordinating efforts with other teams; effort is duplicated and uneven; autonomy and flexibility are valued much more highly than collaboration and long-term efficiency
- teams are made responsible for maintaining more active products than they have resources for; the business comes to count on heroics and although many products are offered, quality and response times are poor and competitors have more up-to-date feature sets
- teams launch “V1” of a product and then are re-assigned to focus on another product; engineers are given limited opportunity to develop architectural expertise before being reassigned elsewhere; sense of ownership suffers; architecture rots in place as only critical patching is permitted
- teams avoid choosing service or product related names since there is the expectation of frequent product focus reassignment; or in the case of contracting, the business usually fails to win a contract renewal for subsequent work beyond initial efforts (or fails to direct the expertise developed in the contract into their own offerings)
- career growth is narrowly defined to include skill acquisition only; there are no levels; hiring is limited to a narrow band of experience ranges; mentorship is not a priority since recruiting purposely attempts to hire engineers of similar ability
- in addition to discouraging technical hierarchy, non-technical career growth is also narrowly defined to skill acquisition; leadership roles available to individual contributors are end with becoming a team lead and are not considered a promotion but a lateral
- being a generalist is actively encouraged (makes it easier to assign you to something new for the next project) and developing deep architectural expertise is discouraged
This leads to key questions to ask when evaluating any engineering organization, whether you are a part of it, considering joining it, or contracting with it:
- Against what standards can I expect the engineering organization to deliver? How can I judge the likelihood that the organization can deliver high quality, consistent work across all features and beyond V1?
- What capacity is there in the organization to take on work? What evidence is there that underperforming products and technologies are regularly pruned to make room for new opportunities or to continue or increase investment in successful products? How much does this organization rely on heroics to make up for poor planning?
- Who are the architects, the mentoring engineers? What are their visions for the organization and products and the technologies they work with? What evidence is there of allowing people to specialize, to learn and own something deeply long-term?
- How are the teams named and organized? Are they aligned to products and services? Do they share processes and standards? Is a sense of product ownership actively encouraged? When a product is sunset, how are the engineers helped to find new homes in the organization? When a new project is undertaken, how is it staffed?
- Are there career ladders — i.e. technical leadership and people management? Are there examples of people that have “risen the ranks” more than a single “rung.” To what extent is first line and middle leadership valued? Is it considered a promotion? Do they hire junior and staff engineers or is hiring limited to senior only? Are senior leadership positions routinely staffed from outside?
It’s the beginnings of a “sniff test” there. I expect I’ll be writing more on this. Comments?
Photo by Csaba Tomcsak from FreeImages
Allen at Automattic 