Weeknotes 06×05: Two successes and Split universes and Product clarities

This week’s weeknotes go over a couple of things that have been a bit of a challenge, but that I’m pleased about the outcome with. The first touches on the challenges of coding and tech team management. The second looks at the joys of raising things honestly at a management level. I’m not sure if they’ve of any use, but maybe it’ll inspire some questions, and serve to connect with others in similar situations.

The week started out with a bang. I was pretty tired by Monday morning after a few good, but really long days off. At work though, we were up against it, as a dev team. With our user group coming up in a week, we needed to bring a new feature together, which involved the usual complexities which make technical projects so challenging, yet also satisfying:

  • working out solutions to complex, inter-related puzzles
  • implementing it in a technology we’re not necessarily very experienced in
  • understanding someone else’s code
  • bringing everything together across different members of the team
  • setting up, understanding and debugging code flows with three services talking to each other
  • liaising with the user/support team to get spec and documentation materials written, in between them getting ready for the user group
  • liaising with product owner – or deputy, in our case – to answer product questions that arise, in between them getting ready for the user group

By Monday we knew what we had to do, code wise, and what our challenges were. But we weren’t sure what our solution was – . John had had a good idea, and I wanted to help out, either directly with code, or indirectly by clearing some space for him. With John or on Tuesday, and me in a Board meeting on Wednesday morning, we’d have to be very smart indeed about keeping each other up to date, and swapping code and notes back and forth.

(To be clear, this is not a good situation to be in. (Previous weeknotes were a precursor to this)[https://weeknot.es/weeknotes-06×04-get-things-done-or-get-things-delegated-f11b8c55327b] though, so we weren’t completely unprepared.)

In fact, there was no way we could be that smart – nobody is that good, unless they’ve somehow been working together without speaking to each other for years already. I’ve known John about 3 months. Neither of us know the code in front of us, or the real answer ahead of us.

So, a decision. At this point, I made the call to split up, hedge our bets, and work on two solutions at the same time.

Dev team be all like

our dev team be like

This is not what I’d usually do. Usually I’d work this stuff out up front, get a plan in place, then leave people to get on with it. But necessity needs creativity, and plans are fine if you unbeaten the risks involved. We were fairly in the dark here, and there wasn’t even a certainty that either route world work. Sometimes you just have to have a little bit of faith.

For the next few days, we existed in this odd parallel universe setup, two branches coexisting peacefully in git, harsh on the knowledge that we’d only end up using one, but comforted by the truth that we could not, at least, fail to learn some things. Very rapidly.

I backed up the dual universe approach carefully, though. Where there’s risk of failure, there’s risk of people being very disappointed. Some things I made sure also happened as part of the decision:

  • Everyone in the whole team knew what was happening, which made it easier to set expectations and excuse myself from other work.
  • I excused myself from other work to concentrate on my own code. The importance of the user group made this easy.
  • I pushed on getting a “harsh context” in place which sounds worse than it reads. I know that developers – especially me – are prone to thinking that the immediate puzzle to hand is the only one, and that a fix is just round the corner. A “harsh context” aims to remove these two common delusions. In this case, we:
  1. Got together a good set of test cases (which ideally we would already have had), in a Google Sheet for rapid transparency. This would act as our yardstick of progress, not what got reported back by developers’ own intuition.

  2. Set clear times to review progress and make a decision. Actually, we’d already made a call that we would be done by Thursday 2pm at latest (to help prepare comms), and so we had an outline to work to. The actual deliverables changed slightly, but the important thing was that everyone had a time-stick to poke others with.

The planning is everything, hrrrrrrggggrrrr

plan 9 from outer SPAAAAACE

Alex and Hon Mond brought the test plan together, and set up the demo environment.
In the end, John hit some issues that came up too late to make the final cut. I went down a couple of rabbit holes, and it’s not the tidiest result, but it works. We have a demoable release, and we know what works and what doesn’t so we can line up follow-on work easily. The team have done really well, and I think I’m pretty sure I made the right decision. Success One, I reckon.

In between everything else, there was a company Board meeting, and various strategy charts.

Success Two: On Thursday afternoon, I sat down with Luke and Kim to chat about the future of the Hive Pixie product, (which I manage from our side in conjunction with our partner. That’s plot, that is) at a management level. I’ve been struggling to keep work lined up and prioritised recently, and wanted a bit more clarity about how much time we can put into it.

As per last week’s notes, it’s something I’m a bit emotional about, having put a lot of time into identifying a Roadmap and getting buy-in from our partner. And pushing past the emotion, it was a really good, and slightly unexpected chat, that made me realise how tricky it is to run a product by yourself, as a part time job.

It’s tricky to open up all the rationalising that goes into a Roadmap, and to tie it into a narrative that not only makes sense, but that pulls people in as well. It’s tricky to formalise the passion, gut instinct and people’s reactions that you see first-hand at user groups. It’s tricky to keep on selling a focused, long term viewpoint over and over. And it’s tricky to keep on top of that and write it all down while you’re on 5 other jobs the same week.

Alright, stop that para there

weep-achu

(Which is also why a good product owner is an amazing person.)

Anyway, this isn’t success. This is bordering on unreserved ranting. The success came from the measured feedback from the chat, which I could instantly pick up on when working from home the next morning. Feedback I could turn into some templates, some structure, and a process for filing it all in. I have a lot of the dots, I just need to be better at showing my joining up. Here’s the note I made:

Does the process with the most structure win? Structure is clarity, clarity is certainty, certainty is engaging.

(And yeah, one day I’ll open it all up to the wide world. Everyone loves a product process template, right?)

I’ve made a start in this, but am eager to carry on. Just need to find the time. Is it sad to want to do this in your own leisure time?

More generally, working the half day from home on Friday was brilliant. My inbox is half the size it was. Still had a productive buzz the following Monday.

Here I come, inbox zerooooooooooooooo

Samurai Jack

Sorry, no time for links today. Til next week…


Also published on Medium.

One Reply to “Weeknotes 06×05: Two successes and Split universes and Product clarities”

  1. Pingback: Workweek

Comments are closed.