Experience leading engineering teams
Stereotypically engineers are interested in things more than they are interested in people. This is an essential directing of the mind’s faculties that enable us to get a job done, if it is concerning the handling of a thing. Examples include:
As their trait in common, these have the ability to fascinate and inspire an engineer’s mind. There is one “-ing” in particular which, in an ideal world, would belong to this family and exists comfortably as an engaging task addressed at regular intervals. Its neglect is often called out as a failing of engineers:
The tendency to neglect documentation is, sure, a falling-short that sees us lumped with all sorts of Unplanned Work later down the line when we find we’re unable to recall the basic commands or configurations that once made something work well enough that it didn’t seem to need writing about. But it is also a useful signalling, from that part of the brain that says whether we’re into “things” or “people”. By failing to document, an engineer has demonstrated their disinterest in people, even themselves.
There are a number of metrics I use to monitor my leading of any engineering team and chief amongst them is the quality of documentation. By committing unbeatable documentation, an engineer does more than simple boasting; they signal to themselves, their leaders, and their colleagues, that they care about people, enough to want to preclude Unplanned Work, aka “toil”.
A selection of roles described in terms of leadership
I‘ve trudged through a project in which the scenery was changing too fast for us to settle on any useful system of documenting, structuring sprints, or even prioriritising items for a roadmap. We could’ve really used Agile on that one, particularly for its discipline i.e. the confidence to Say No To Scope Creep.
Later in a 12-person start-up as sole engineer, having inherited 100% of the company’s data estate and infrastructure from my predecessor during a strict 2-week window, I saw what technical “fire-fighting” can look like at its worst. No headspace to sit back for a retrospective; only endless tickets and a broken Confluence instance that we were too scared to use in case it fell over.
One of the most inspiring periods of my life was the 2-year stint leading the first successful Data Transformation for one of a vast group of companies broadly grouped by the fact they’d been publishers and were “going digital”. The appetite balanced out beautifully as customers were keen to receive publications faster, and in copy-pastable formats; developers could grow into the new field of cloud & serverless, and shareholders backed us on the understanding that, once you’re in the cloud, not even the sky poses any limit.
Tools that empower leaders in engineering
- Ticketing system
- Documentation wiki/repo deployed alongside ticketing system
- developer-friendly platform like Stack Overflow For Teams enabling transparent problem-solving
Pitfalls to anticipate
- Dilemma: a system is found to be edit-locked for single users at a time, and one of those users goes on annual leave without taking the proper steps to fully close their Edit window. Everybody else is locked out; impersonating that user’s login is possible only if we have credentials-based login and not SSO.
- Disruption: a new engineer joins the team; empowered by their fresh/unbiased perspective and eagerness to impress during probation, they suggest a core ETL tooling is not up to the job and should be replaced by a new custom-code solution. The engineer is talented & experienced enough that their initial attempts at custom code go very well, so that stakeholders are divided in their support for the incumbent vs the replacement.
Solutions to try (one-to-one mapping onto pitfalls)
- Contact the user who has left the session open; if they’re able to open-and-close then all is well and we’ve learned a valuable lesson. If unable, attempt system restore from most recent backup/snapshot. If backup unavailable or restore not feasible, bring in some other priority item from backlog.
- Empower the new engineer to be heard and understood; you don’t want to lose their enthusiasm. If the consensus is they’ve not quite understood the decision logs backing-up the incumbent tooling, conduct a workshop to help demonstrate its use and append a recording of that workshop into the documentation; lean into the debate as an opportunity for everybody to be reminded of where documentation & standards are accessed.