As I prepare to onboard two new developers today (exciting!), part of the conversation will inevitably be around orienting them to my current philosophy of delivering software. I figured I’d share that here too.
First, Caveats
I believe these sorts of things are context-dependent. My current context is as a VP in a smaller organization who’s leading multiple SaaS product efforts with a small team while building up our delivery acumen. And it’s going well.
Some – probably many – of these notes may be widely held; you’ll certainly see them echoed in thinking about agile, devops, and modern leadership. I’m not claiming to have invented these things; I stand on the shoulders of giants. This is a summary of how I’d explain these things in conversation.
What is Innovation?
As VP of Innovation & Products, Innovation is right there in the title. What does that mean?
There are a lot of definitions that I like, but I’ve settled on my own language:
Innovation is the act of continually reinventing ourselves and our approach so we can add value and delight.
I think creating delight applies both to our customers and to our fellow colleagues.
Software Delivery is a Team Sport
Everyone should be able to:
- Take over their colleague’s work in the case of something like an absence or shift in priorities. We keep each other informed of progress.
- Troubleshoot operational issues in the system (at least fundamentally)
- Ask for help or say they’re stuck.
- Push a release confidently.
- Suggest a better approach.
- Pair/mob as helpful to produce the results we need.
- Call a meeting/conversation if one is needed.
I want to work on a great team that levels each other up. I want to do great individual work, but also I want to produce the kind of impact that is only possible with the sum of our skillsets.
Smaller Loops. …No, Smaller Than That.
There are things we do over and over again as a team/organization. The more of those loops we complete and improve upon, the faster we’ll deliver great impact and adapt where needed. Whenever we shrink one of these loops, it’s like compound interest that makes us better over time.
Much of what is below is an extension of this principle.
Question Everything. Especially Me.
I depend on our collective insight. I have a vision and work to find alignment with our team, but we’ll only ever be as good as the issues we surface and resolve.
Questioning me often involves a little back and forth because I’ve typically put a lot of thought into something and so I need to go deeper. I’m working on “leading with inquiry” so that I don’t come off intense or defensive in these moments, because having someone improve our vision/tactics is almost always a favorite moment later.
You are Not Your Code
I’ve written plenty of crap code. I’ve been lucky enough for people to provide great reviews and level me up. That’s what I want for everyone.
It’s good to remember that anyone can teach, anyone can learn, and we need ourselves to be critical of each others’ code so we can get better. That requires us to he humble about our code, and to understand that our code is not the measure of our worth as developers
The Value of Shitty First Drafts
Get something out there and iterate on it. Don’t try to make it perfect. There is a cost to the delay. Shitty first drafts win over that every time.
Don’t get me wrong: great first drafts – when they happen – are even better! But too often things go undone or untried because we don’t feel they’re polished enough.
I’ve re-learned this lesson a lot of times. I’ll probably keep re-learning it.
Feedback is a Gift.
I truly feel this way, and a wonderful human/leader I worked with (shout out to Jeff Gallimore at Excella!) felt that way too, and taught it to me. His ability to receive feedback in all forms really set him apart for me (and still does).
When someone wants me or my team to succeed enough to offer their critical feedback, I want to honor that. I love for as many people to move toward this as possible, but that’s a personal journey and doesn’t happen overnight.
I Want a Team of Leaders
I am very much inspired by the “leader/leader” model espoused in L. David Marquet’s book, “Turn the Ship Around” (again, big credit to Excella there). There’s a lot to unpack in a whole book but I’ll sum it up by saying I want everyone to feel like they can be a leader at any time, and I want our team to operate as an empowered group of leaders with a common goal.
The 30 Minute Rule
Try to figure something out for 30 min before asking for help. You’ll learn stuff and become more confident in your problem solving ability.
Don’t wait more than 30 minutes to ask for help when you’re stuck. Sometimes it just takes another person, and that’s fine! We will all get to learn something.
Effectiveness over Predictability
I’m a big fan of Scrum in many cases and have a background in it, having been a certified trainer for the CSD certification.
However, I believe Scrum is optimized for predictability. This is great, especially in environments where a lack of predictability is harmful. However, predictability can sometimes hamper effectiveness (as we see in the backlash articles against Scrum, which often make good points about its effectiveness).
In many environments – high performing teams or small companies where communication paths and feedback loops are small – Scrum is not the right choice.
If you’re already effective without it, optimize for effectiveness. In my current context, that means Kanban and the continuous pull of work (with enough slack in the system, of course)
Work Out Loud / Radiate Information
This one is huge for me. Work “in public”. Start pull requests early. Share your thinking along the way. Always be “journaling” – posting updates on tickets, adding to wikis, sharing what you learn with colleagues.
Failure Leads to Inquiry
Sure, I stole this directly from the concept of Generative Culture, but it resonates enough that I try to put it directly into my approach.
Things will go wrong. We will learn as a team and as individuals. It should be OK to say you messed something up, and it shouldn’t come with consequences. It should be on us to build our systems such that the blast radius for those things is small.
Asynchronous Communication
Less meetings. More chats and wikis and empowering people to make decisions. Leave messages and don’t expect immediate responses.
Live Artifact Collaboration
Don’t share office file copies etc. Make them live collaborative docs and share links. Something magical happens.
A recent example of this: rather than downloading some analysis in an Excel sheet, we started making it a link. Now I can add questions as comments using the review tool, and even assign those to someone, and we see the whole history right in the document.
Unblock Others First. That’s My Job, too.
It may seem counter-intuitive because people (understandably) don’t like to context switch. But unblocking each other (and collectively sharing what we learn) is often more valuable.
I try to be clear that this extends to me, too. If I’m doing something, I need people to ask for the help they need, and I need to stop what I’m doing to unblock and empower them.
Doing the Best Work of Your Life is Not a 9-5 Thing
Up front: this doesn’t mean “always do extra hours”, which is how a lot of the industry likes to weaponize it. Nor do I expect everyone at a job to be trying to do the best work of their life.
But, this means if I’m getting close to something that could help someone, I finish it. It means if taking a little extra time makes something much better, I do it. I optimize for being as impactful as possible. That also means that some days I’m less effective, and I have to accept that and focus on less impactful work those days.
Balance doesn’t mean 50/50. I’ve been putting in just enough more time to be really effective, and it feels great. And I know I can take downtime when I need it. If my team trusts in that, I want them to be able to opt into it too. But that trust and opt-in is extremely important so that this one doesn’t backfire.
Automated Testing
It’s an important tool in the toolbox. Where it helps us move faster and with confidence, we should do it. That is probably more places than we think. I love TDD and the way it forces me to break problems down. But mandating the practice of TDD across all code or automation for its own sake isn’t helpful.
Deliver as Continuously as Possible
Favor small work that flows more quickly toward production. Try to deliver many small chunks of work. Use things like feature flags to ensure work can go out the door without being activated, so that work doesn’t have to be held up.
The Prime Directive
The Prime Directive is important enough that I’ll repeat it directly here too:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
Improving the Work is More Important Than Doing the Work
At least slightly. Improving our approach to the work is compound interest – it builds up over time and affects all future work. Thus, we should do it sooner rather than later.
Where These Principles Conflict, What’s Best for the Humans Wins
Some of these principles are in natural tension with each other. It’s bound to happen.
When I hit a conflict between these things, I try to think: What is best for the people on my team who are involved? What’s best for the people in our organization? Usually that helps clarify the right choice/action. People make up a company; we have to be people and look out for each other first & foremost.
That’s a Wrap!
I may update this post soon as I inevitably think of something I left off, but: what are some things you expected to see but didn’t? Sound off in the comments!
Leave a comment