(Part One of The Seven Areas Of Software Management)
For anyone coming into the manger role from a software development background, this is the area which is easiest to grok — “what are the means by which your software engineers create work product?” Now, while a number of managers stay hands-on engineers, coming at this area from a management perspective is different. Your position is to ensure that how your engineers are using tools and processes to build software is being done the right way, with regards to the short and long term needs of the business. That turns out to be hard as the following are in tension:
- What your engineers want. Usually this is either not changing the status quo, or alternately wanting to abandon it for something completely new.
- What the business wants in the short term. Usually this is ignoring anything that doesn’t make immediate impact. (i.e. accumulating technical debt), and so any work on tools or processes.
- What the business needs in the long term. Usually this is retaining strong, experienced engineers and ensuring the future system remains simple as it grows, both to maximize future ability to make impact. Which means paying down technical debt including addressing deficiencies in tools and processes.
- Where the current sunk costs have put you. This is usually in a position that none of the above are easy to reconcile.
As per the introduction, your job as a manager is to get on top of the tactical position, start thinking about strategy, and so start planning action.
Understanding Your Position
- For all software engineering processes — Languages, Code Style, Code Reviews, Unit tests, Integration Tests, Design/Architecture Reviews: What is being done by your teams? What are organization policies? What are industry best practices?
- For all software engineering tools — IDE, Build tools, Deployment tools, Host(and other) Provisioning, Security Tools, Telemetry, Alerting: What is being used by your teams? What are the organization standards? What are industry best practices?
- Understand your team’s pain points with the above.
- Understand partner team (particularly your tools and/or architecture teams) pain points have with your team.
This a good point to check my own honesty, as when I look at what it means to do a great job on the above for a 7 engineer team, it is a full time job. Meanwhile there is 6 other areas of management. Which comes to, I am not the first person who when I read management literature I think “you can be the best delegator in the world and still there is no way you can be on top of half of that”. Now, as per my philosophy, in management you will never hit ideal; you will repeatedly, tangibly miss. But to minimize misses, the question is how much time should be spent on these particular questions? My filter for this (and all areas) is 1:1s (skip 1:1s as a manager of managers)— occasionally checking in and using my engineers’ judgment of pain and options to address it. That trims the space to something I can feasibly spend time on building a strategy across.
Getting to a Strategy
From the last section, you should be heading towards a prioritized list of pain points. But sometimes that isn’t easy, as in order to compare options you need a quantitative value on something hard to quantify. Now, anecdotes can help (“over half my engineers cited our poor build tools as their number one pain point in 1:1s”), but particularly as your organization gets bigger, you need to find mechanisms. The two I have seen are (1) measuring customer pain by diving on the root cause of all customer impacting issues to the point you can say which specific tool or process was the ideal place to avoid it, and (2) measuring your engineers pain using a survey. Neither is perfect, but they both bring good information to a trade-off decision.
To get to a weighted list of actions, the next step is understanding costs of solutions, and that brings two problems on opposite ends of the spectrum. The first is there is no more tempting area than tools and processes to think a silver bullet will solve all your problems. Indeed Fred Brook’s 1986 “No Silver Bullet” essay was on exactly this topic. So to counter the silver wielding revolutionaries, you need to do them to compare the silver bullet cost vs benefits to a more incremental option.
However, since this is a rapidly evolving (more cynically, a slowly evolving and rapidly changing) industry, you can be in a position where multiple revolutionary changes do pass cost/benefits. At that point my advice is:
- Time and focus is limited not only for you but for your team, and so only one big change at a time;
- Beware of bad bullets, choose ones with overwhelming industry and/or organizational momentum
- Good looking bullets can turn out bad, so don’t jump too to use one early unless the pain is acute — let someone else tackle the early adopter issues.
And so for options which don’t pass these three thresholds, be willing to invest in incremental improvements, even if it seems likely it is throwaway in the long term. As Keynes said, in the long run we are all dead.
The other problem is the inverse: inertia that stops an option getting the resourcing it needs to succeed. This is a problem even when you are sure a change makes sense, as while you personally have time and focus to help, one of the early lessons of management is you are unlikely to have the contiguous time and focus to hands-on deliver, so you need help.
Can’t you ask your team to do it? I have found junior engineers can be convinced to act on an ask from “authority” (i.e., you), but the downside is they are inexperienced and so will need senior guidance to get it right. So what about senior engineers? My favorite line to my senior engineers is “you never do what I want, but I have learned that is the right thing” — i.e., it is hard to get them to do something unless they want to do it because they believe it is the right thing. So how to get them to see it’s the right thing? The challenge is that while senior engineers complain about the state of tools and process and how “we” collectively need to make them better, almost all of them don’t want to spend their time making them better; they have more important things to do.
Now part of this is they will blame the business, saying this is not recognized/rewarded vs things that impact the top or bottom lines in the short term. There is always truth to that, and that’s your responsibility to address (as I will talk about later in the “Company” section). However it’s usually more, in that unless you are going the silver bullet route, this type of work is high toil and low on intellectual learning/challenge (i.e., fun), and so your senior engineers prioritize it lower.
So what to do? For this to succeed, you need someone passionate about the goal to do the hands-on toil to make it succeed. Now if you are following a silver bullet route, you should find that. But outside the silver bullet route you still may find someone, although with the challenge it may not be in your highest priority option. Engineers have their pet passions. And so a passionate owner is itself a reason to prioritize an option higher — “Lean in on empowering your passionate team members” is a pretty successful management technique. Now what to be careful of is since empowering the passionate is going to cost you time, focus and capital, you need to make sure you believe in the value of what they are passionate about. But if you have that, go for it.
However, what to do if you don’t have a passionate tech owner but an area needs to be addressed? Here I have learned to never underestimate the value of a leader regularly and visibly spending their time and focus on an area; my saying is “People will follow their leader’s focus”. I will write a later blog post in depth, but one of my earlier lessons on this was at AWS when we were looking into “Network Performance Variability”, an extremely frustrating and high toil area to understand across a ~500 person engineering team. Yet all it took was my double-skip manager turning up every month to a 6-page review, being engaged and asking hard questions, and doors opened in terms of the whole org being interested in not only understanding, but fixing the root cause problems.
In any case, this is all the things to understand, so you can choose 1–2 of the most impactful actions and goals from the next section.
Potential Strategic Actions/Goals
Directly helping with large engineering decisions, e.g.,:
- Goal: Drive to consensus on “very important engineering strategic decision” X. This will be measured by a document reviewed by all stakeholders, including a delivery plan, fully committed to by the organization
Improving teams engineering process, e.g.,:
- Goal: Across year, all code going to production has been reviewed
- Goal: By EOY, increase unit test code coverage to 80%
- Goal: By EOY, have fully functioning CI coverage
- Goal: By EOY, have fully functioning CD
- Goal: Ensure the team submits 3 design reviews across year
- Goal: Ensure X big project has an architecture review before coding in earnest starts
Setting goals to act as quantitative feedback of status:
- Goal: Across year, have only X customer impacting issues caused by new bugs
- Goal: On your teams survey get 80% agrees on the question “I have the appropriate tools needed to do my job”.
- Goal: On your teams survey get 80% agrees on the question “My manager emphasized quality”.
Improving engineering practice by delegation, e.g.,:
- Goal: By EOY establish X person as tech lead of Y, making all architectural decisions
- Goal: Have everyone in team do at least 1 project to improve engineering process or tooling
Improving tools, e.g.,:
- Goal: By EOY move off custom tool X and onto the company standard
- Goal: By EOY convince company’s tool team to accept your teams better tool “Y”, including taking on support.