Software engineers will sometimes talk about the craft of software development. The term invokes a sense of art and skill cultivated over years of experience and tribulations, and certainly sounds cooler than framing the act of building software as continuous reapplications of CRUD apps to streamline various business processes. If development is indeed a creative endeavor, then of course its practitioners are artisans, paying their dues via CS degrees and code camps, entering the industry as apprentices of the craft of development, en route to shaping shaping their own brand of programming with industry experience.
Hmm. I’m not sure I believe what I just wrote.
Anyway, as I’ve stayed a manager of engineers—and teams of engineers—for the better part of a decade, my mind naturally wanders to management to think about whether a parallel exists in my domain of expertise. And true enough, some aspects fit the notion of craftsmanship just as well:
- Good management can be seen as an art;
- It requires practice and iteration;
- Masters are easily distinguishable from novices;
- Each manager eventually develops their own unique style.
In fact, compared to the laws of computing that constrain the act of programming, there’s a lot more freedom and breadth of actions available in management, and the diversity of humanity means that management efficacy is heavily influenced by skill and experience.
The flip side of all that lack of constraints in solving management challenges is that feedback loops are notoriously long and indeterminate. One of tangible outputs of craftsmanship, at least in the traditional sense, is the end result itself—the sculpture or restaurant dish or glass bowl, or with engineering, an app or a piece of software architecture. When managers engage in our so-called craft, it’s hard to nail down exactly what artifact we’re shaping.
Though it’s much too early for me to tell whether this is “right” or even applicable to others, one intermediate goal I’ve given myself is to add intentionality to words and actions. That is, for every process and procedure and decision, I try to think through the why and spend time to articulate the reasoning, even if it ends up flawed. By leveraging past experiences when available and engaging in thought experiments otherwise, it becomes increasingly possible to detail how and why of taking an action, which in aggregate is really just developing a managerial style and playbook. Over time, fleshing out these rationales helps separate the deliberate from the arbitrary.
Concretely, what this means is that I constantly and consistently try out a bunch of new stuff, see what sticks and refine what feels coarse. For instance, for my staff meetings, this has been the course of development through the past 4–5 years:
- Invited to the CTO’s standing meeting with their managers and senior engineers, and saw the value of holding a regular discussion forum for senior people on the team
- Ran my own weekly staff meetings, limiting the scope to people managers to keep the meeting smaller and within 30 minutes
- Added a running agenda document to keep people on-track
- Added an Action Items list in the agenda
- Added a News section to the agenda to regularly, explicitly pass down information
- Created a frowny face 😕 system to the Action Items list, plus regular check-ins at the start of the meeting, to keep people accountable to signing up for to-dos
- Added a section to go around the room (which works because the meeting size is kept small) for news updates to encourage everyone to participate
- Made myself the primary notetaker for the meeting to avoid always having the quiet participants volunteer to be the secretary
- Modified the “around the room” round to have people just give whatever is on Top of Mind, as some weeks there are no news from the team
- Bifurcated Top of Mind section to be about something personal and something work-related; people wanted a chance to know each other better, particularly in COVID-induced virtual meetings
If I were to draw an analogue to software engineering, this almost feels like a microservice that starts out doing something simple and layers in additional complexity over time. That, in and of itself, isn’t a bad thing! There’s been good reasons to impose more structure to the meeting, and it’s become a format that I’ll carry with me for future staff meetings with a good understanding of why each aspect is useful. And this will continue to evolve in the future, as folks give me feedback on what works for them and what feels superfluous.
Almost like a craftsman.
