This started as a blog post for the HI Digital Solutions blog, and never got posted for some reason. I’m pretty sure it had to do with it being drafted in April 2020. I think some things may have been happening around then. Anyway, I’m (re?) posting it here. Enjoy!
H.I. Digital Solutions (DS) has been working through improving our employee evaluation and growth processes. As part of exploring how we could improve, I scribbled a few questions on a sheet of paper. Then I started to answer them.
This somewhat unusual blog post is a very lightly-edited, typed-up version of five pages of longhand, in which the original few questions quickly turned into a written Socratic dialogue (in a non-strict sense). The topic being explored is “what should we pay for?” Put another way, what are the desired outcomes DS employees produce?
The question to address: How do I know whether I am providing value exceeding my cost?
What is value?
Systems that make or save money for the business.
Just those?
Well, also systems that give the business new capabilities, which are strategic or make or save money.
That’s vague, can you give me an example?
Let’s say there’s a market report that contains useful insight for your customer, and it takes two weeks to assemble. If you could deliver it daily (cutting lead time from two weeks to a few hours), that might be a new revenue stream – OR – it might establish your company as better-informed (therefore a market advantage) – OR – it might open up a new niche somehow.
Okay. So outcomes are tied to value?
Yes, explicitly, because we pay for outcomes. We pay for products from companies, and outcomes are the “products” of our employees.
That leads to the logical next question: What are the valuable outcomes to DS?
Like I said, systems that make, save money for, or give the business brand new capabilities.
What does that look like for software folks?
They’re the ones that construct the systems. They also design, test, and install them. And so they have to ask a lot of questions about what the business processes and outcomes are that are affected. That puts them in a good spot to suggest alternative approaches.
What do you mean by “alternative approaches”?
Sometimes the right thing to do is to write software. But sometimes, the right thing might just be to put up a sign, or cc Accounting on a regular report, or to use Excel.
What you’re saying is there are times when a software person might better serve the business by delivering a process recommendation, using existing tools?
Right! Or even recommending NOT doing the work.
Tell me more about what that means.
Let’s take a contrived example. Let’s say you have a monthly financial report that someone in the business wants daily. Your team explores the issue. It’s technically feasible. It’ll take M months and cost D dollars. In the course of investigating, you discern that the source data behind it only gets updated weekly, and the business already reviews and reacts to indications in the source data weekly. Your team estimates the business will only get 1/100 D value per year if you build the system to deliver the report daily. So the sensible thing is to recommend NOT doing the work.
If I knew Latin, I’d tell you that a contrived example can prove anything, in profound-sounding Latin. But you’re quite convincing. Let’s tie it back to outcomes, though. What are the valuable outcomes a software person might achieve for DS?
Running through what we’ve already said: (1) saving time and money by recommending NOT doing a project. (2) Delivering a system that saves money for the business. (3) Delivering a system that makes money for the business. (4) Delivering a system that gives the business a strategic capability.
Are 2-4 all the same? Delivering a system?
Maybe. Maybe they’re really (5) Delivering valuable software or systems and (6) Identifying business value.
Is “identifying business value” really an outcome?
Maybe not. You could identify but never act on it. Probably not.
Are there outcomes besides recommending (1) and delivering (2, 3, 4 and maybe 5)?
Oh! Sure! That’s growing the team, and growing the team.
Those sound remarkably similar to me.
Sorry. (7) Expanding the capability of team members to achieve valuable business outcomes (such as delivering software), which can be summarized as – but is different than (8) Expanding the team by recruiting, interviewing, and hiring new team members when capacity needs to be increased.
I see the difference. So, delivery, non-delivery, growth? What else?
“Delivery” might be slicing things a bit narrowly. It’s not just about handing over a floppy disk. It’s about delivering, installing, operating, monitoring. Or if your team isn’t responsible for all of that, keeping the teams that are happy. If the software is hard to monitor, your Ops counterparts will end up grumpy.
We should explore that more. But before we do, you mentioned other teams. Is it just other teams, or is there something more general here?
Yes! You’re right. There are other stakeholders too! There’s probably something about satisfied stakeholders. Let me think for a minute here.
While you’re thinking, can you also consider the tension between satisfying stakeholders and (1) NOT doing a project?
The outcome we’re probably after for satisfied stakeholders isn’t 100% rainbows and unicorns, is it? Sometimes things don’t go someone’s way, or a pet project gets squashed, or someone has to subordinate their desires to the bigger needs of the business. How about we start with a simple outcome that we can revisit? (9) Satisfying stakeholders so they want to work with you again.
Sure, I suppose. There might be a way to improve that, but as a starting point, I’ll go with it. Let’s go back to what you said earlier about other teams.
Other teams, like Ops or a help desk, or a downstream team, should be kept happy. The software needs to be valuable — do something valuable — but it also needs to be low-friction so people don’t dread it.
What do you mean by low-friction?
Think of what I already mentioned about the things like installing and monitoring. Plus there are things like usability — does using the software simplify life, or just move pain around? And for future software teams taking on the project, they will want to be able to modify it and deploy it with confidence.
There’s a lot there! Some of it—like users able to use it—feels like it falls into the category of satisfied stakeholders. The last part, about future teams, seems like there are two ways to go. You could tie it into delivery (2, 3, 4) somehow, or keep the focus on future teams. What do you think the best approach is?
To me this feels distinct from delivering a system, somehow. The “future” part of it makes me think the outcome we want here is related to sustained ability to keep producing results and being productive. Hmm. So there’s an aspect of sustainability for the work delivered, but probably also for the user.
Let’s try to tie off the “work delivered” part of this. What do you mean, and what’s the outcome?
It’s like I said, “sustainability for the work delivered.” After you ship 1.0, you should be able to keep working toward 2.0 without being bogged down in regression testing and struggles with deployments and all that.
So what’s the outcome you’re looking for?
Keeping it simple here, (10) Develops software that can be modified and deployed with confidence that it works.
Simple works. How about sustainability for the worker? What do you mean there? Rest breaks?
No, not that. I’ve heard it said that one mark of a good leader is that when they leave their team, it doesn’t fall apart without them. It shows they’ve invested, developed, improved things, and created a culture that does not depend on their involvement.
This sounds like a special case of (7)?
It does, with that lead-in. But that’s not what I was after. It ties in, though. You see, that good leader has some sort of system, not just luck. Or personality. So the team can continue without them, AND the leader can go on to a new team and replicate (or sustain!) their success. We want that sort of thing here too—people who can sustain good outcomes.
You might be getting into a meta-outcome?
Maybe. What if we keep it meta and try to phrase it (11) Consistently delivers desirable outcomes to their team and customers?
Is that too squishy? What you’re trying to get at is they sustain their work, but the “desirable” and the “and” make that harder to evaluate.
True enough. I want to say something about reducing entropy, but I just realized that doesn’t necessarily imply delivery, or satisfied stakeholders. Cleaner software and slightly less grumpy stakeholders isn’t a great outcome. So let’s simplify and go with (11a) Continues to deliver good outcomes—OR MAYBE—if we want self-growth (11b) Consistently delivers good and continually improving outcomes.
We can probably work with that. One of those options, anyway. That “entropy” idea is interesting. What do you mean by “reducing entropy”, and what does that look like?
Well, entropy is disorder in a system (“between gravity and entropy, we don’t stand a chance / everything goes downhill while it falls apart”). A good software engineer—or really, most employees except maybe demolitions technicians—reduce entropy by putting things in order: structures, systems, namespaces, useful vocabulary—and by solving problems that create disorder.
So you’re talking technical entropy, code and build systems and the like?
Huh. I was. But now that you mention it, there’s non-technical entropy. Assumptions that don’t hold, processes that could be unified and simplified but aren’t, disagreements among business areas. And maybe it’s not technically entropy, but ossified processes that slow work down and might cause work disruption. I’m thinking projects that take longer because nobody wants to interface with a particular group—so they route around it and there’s turbulence, like a rock in a stream.
Reducing this non-technical entropy, what does that look like? Can you articulate an outcome that’s not subsumed in, say, (2, 3, 4, 5)? Or (9, 10, 11)?
Yeah, I’m not sure. The combination of delivering value plus satisfying a broad range of stakeholders probably captures it. Maybe it needs to be made explicitly, but I think it’s hard to sustainably deliver valuable software, satisfying your stakeholders, if you’re not reducing non-technical entropy—both inside and outside your team.
Does that same argument apply to technical entropy?
It might! Let’s take, say, TDD or build systems. You can deliver software without these. Maybe even repeatedly. But without these kinds of things—things that solve problems of correctness, repeatability, modifiability—you start to reduce velocity. I assume.
You mentioned solving problems just now, and you’d mentioned it earlier. Is there something there we should pull out?
I’m pretty sure some people would argue that “solving problems” is what engineers do. Some do it with computers, some with roads. Building software, debugging, and even deciding NOT to do a project all fit under problem solving. Is that too big to be an outcome?
Flip that around. What might it look like if it were an outcome? What does problem solving look like as an outcome?
Just saying “solve problems” isn’t enough, probably. How about (12) Creatively solves business problems with the long-term interest of the business in mind?
That sounds promising. Does it overlap with our earlier outcomes?
Probably, but it takes a different approach. It seems distinct, or at least different.
Could the earlier ones fit into (12)?
I’m going to argue there’s enough of a difference that we should keep it separate for now. Besides, if you look at it broadly enough, it might be the only outcome, with even (7) and (8) falling into it.
It seems we’re wrapping up. What else? Any other outcomes we’re missing?
Is there anything around working transparently? Or might that be a value, or a method for achieving outcomes? Probably, I suppose. Same for collaboration. It supports outcomes. Same for things like ethics—that’s stakeholders and sustainability. And leadership probably is also a tool or method.
So we went from wanting to know how a software engineer can “deliver value exceeding my cost” to a short list of outcomes. Is that satisfying?
I think so. I think there’s enough granularity in the outcomes to make distinctions between skillsets and skill levels. And they’re able to be decomposed so we can help someone build the skills to achieve those outcomes. That’s probably more work—future work. Thanks for your help!
You do realize you’ve just been talking to yourself, right?
Yep. Well, writing to myself. Thank you anyway, self!
Outcomes “Discussed” Throughout
For convenience, I’ve gathered all the items discussed throughout this post here. Recall that as the “discussion” went on, several items were crossed off the list, decomposed, or rephrased.
- (1) Saving time and money by recommending NOT doing a project.
- (2) Delivering a system that saves money for the business.
- (3) Delivering a system that makes money for the business.
- (4) Delivering a system that gives the business a strategic capability.
- (5) Delivering valuable software or systems.
- (6) Identifying business value.
- (7) Expanding the capability of team members to achieve valuable business outcomes (such as delivering software).
- (8) Expanding the team by recruiting, interviewing, and hiring new team members when capacity needs to be increased.
- (9) Satisfying stakeholders so they want to work with you again.
- (10) Develops software that can be modified and deployed with confidence that it works.
- (11) Consistently delivers desirable outcomes to their team and customers.
- (11a) Continues to deliver good outcomes.
- (11b) Consistently delivers good and continually improving outcomes.
- (12) Creatively solves business problems with the long-term interest of the business in mind.