Toward the end of 2019, I was transferred to a new team at Toyota Australia, the Toyota Used Vehicle Platform. I would be the Scrum Master and UX Designer. We were tasked with bringing an improved experience to our visitors, and look to incorporate financial repayment options for these used vehicles.

The used vehicle site had been suffering from neglect. A product with great potential, but little attention.

I was incredibly lucky, the Product Manager involved gave me, and a super talented full stack developer(Andre) pretty much free reign, under one constraint; all vehicles that would be eligible for a finance option, i.e. a weekly repayment cost, needed to be live by March 2020. Whatever we wanted to do to improve the experience at the same time, we could.

So, Andre and I took huge advantage of this. We story mapped the exisiting site, using the Information Architecture as our starting point. From there, we could easily prioritise the biggest opportunities, and make plans on reducing risk and increasing our delivery speed.

The biggest question on our mind, was, how could we quickly and easily give visitors a weekly repayment option, if not on all cars, but a small subset? There was some complicated criteria for some of the vehicles, as to whether they were eligible, so we needed to find the quickest way to market.

We looked to firstly consider the user journey, make it easier for the user to “window shop” cars. We then considered what the business wanted, which was essentially more email leads being sent from our site straight out to all the Toyota dealerships around Australia. Finally, we thought about how we could pair back the design, only give the user the basic/essentially details, and in turn, make space for the financial repayment data to come into the design.

This was what we started with:

Our main assessment of the experience, was how unclear it was for the user. What were we asking them to do next? Once a user was scrolling, did we want them to click on a car, get their own car valued, or what?

We paired the UI back. We focused on making it clearer what we were asking the user to do. Essentially, we wanted them to enquire about a vehicle as quickly as possible, or look into the details of a vehicle a little more closely.

Once we arrived at the above UI, we got to work on the financing options available for our visitors. We wanted to get this out safely, but fast. We assessed our options and decided, the first release, would have the financing option display only when a user clicks on the “View details”. Through this approach we would test the stability a new API to one car at a time. If we could get that reliably working, we could increase the capability from there.

As we increased the financial repayment options on the UI, we continuously refined the experience, continuously stripping out unnecessary features, making it much more succinet and less demanding.

After testing our approach on a subset of vehicles, and increasing that subset incrementally, we built confidence in our product. If we caught bugs, wrote tests and ultimately released a stable new Used Vehicle experience.

All of this resulted in some amazing analytical results for a team of essentially two. Over a 6 month period, from Jan 2020 – June 2020 we saw a 97% increase in traffic and a 35% increase in user generated enquires as compared with the same 6 month period in 2019.

It astounds me what you can do with a tiny team, some trust from above and autonomy to get the job done.

Earhart – the atlantic and managing compromises

Back in 1932(May 20), Amelia Earhart flew across the Atlantic as the first solo female pilot. As I recently discovered, progress towards this goal involved a significant number of compromises. When originally asked to cross the Atlantic by plane, in 1928, she was told she wouldn’t be allowed fly, nor would she be paid. But she accepted nonetheless, perhaps this eventually lead her to crossing the Atlantic solo, not to mention many other flying accomplishments she would then go onto achieve.
More recently, as I pursue the perfect environment for software development and my team, I need to remember, this push toward perfection is a fantasy. Nothing will be perfect, and the pursuit of perfection is nonsense. Very few things in life come and go without compromise, and that is not a bad thing, let me hold that thought.
Amor Fati is a wonderful phase, latin, meaning“alove of fate”. I have a sticker on my laptop to remind of this everyday. We can’t force our expectation on a job, event, situation without setting ourselves up for the fall. I believe, without knowing Amelia Earhart, that she understood this. She understood that this would be her opportunity, not ideal, but her chance, and if she was on the inside, her chance to influence it. Being in the fold meant she stood a higher likelihood of achieving her bigger aspirations. She could have said no, conveyed some message to herself and others that she remained true to her desire to fly the plane. But this would have left her on the tarmac.
Understandably, my choices in life are not nearly as glass ceiling shattering as Amelia(as a father of two girls, I’m very inspired and hopeful for a more equal society, as we stand on the shoulders of women like Amelia Earhart). Limited expectations without losing hope for the bigger aspirations can be a helpful mindset. Epictutes reminds me:

“Demand not that events should happen as you wish; but wish them to happen as they do happen, and your life will be serene.”

Brene Brown’s latest book, Dare to Lead has had a surprising impact on me. I’ve found myself reflecting on a lot of what she has to say. She is a captivating writer, someone you come away feeling like you know. I’m not sure if it’s her openness to share personal experiences, that are so helpfully shattered through her book, or her ground way of communicating.
Nonetheless, Dare to Lead, amongst many other things; guides you through a testing framework for uncovering your values. Brene Brown goes as far as to suggest you shouldn’t have more than two values, describing them as your“core”vales. Her approach has been really helpful to me, here’s why.
I’ve been through a few attempts at trying to uncover personal values before, none of which have really resonated. I’ve found some confusing and others too fluffy. Afterall, a large list of values are, essentially all good characteristics, they all have some merit, so why choose two? Why not six? And here in Dare to Lead is the point of difference; the thought is if you have more than two, you sort of have none. It becomes unclear which values to compromise on and which to hold strong on, if you stand for everything you stand for nothing. It helps clarify, at least partially, what are you willing to go out on a limb for and what can you let go?
The moments that call for compromise in order to move forward, pull you into some sort of active or passive action, and after all, progress is everything. So, what are you willing to not compromise on, and what are you willing to let go. If you you’ve struggled with this, as I have then the establishment of two core values can be a really helpful starting point.
I plan to test myself and these values, firstly, to see if my narrowing is the right fit for me, but also, to not become an impediment, because I’m fighting on every front.
I can only assume Amelia Earhart knew this, and was willing to compromise on some things, and not on others.

Stories, users, and the art of slicing!

Stories, users, and learning

This month I had the pleasure of spending some time with Neil Killick(http://agilemelbourne.neilkillick.com/) and a few others learning all about story slicing. 
It was incredible. Yes, I realise, that’s a fairly strong statement, but I don’t think I’ve been in a situation before, where I’ve been able to apply so quickly what I had just learnt. 
I’m very fortunate to work for the best company in the world, literally, Salesforce.com has been ranked #1 by a whole heap of evaluators around the global. That means, I’ve got the space to try new things, and my colleagues are open to working in different ways.
Within hours of this session, I was able to take what Neil had taught us to work and apply it. Where once I had struggled to know what to do with a story, I feel I can now take it to the mincer and slice it in several ways to make it more feasible for everyone.

The following Monday following the session with Neil, I was sitting down with my team running a sprint planning event. During the session, we considered several “user stories” to take into the sprint. Having Neil’s guidance, I could, within moments, look at a story write it up on a whiteboard and apply Neil’s magical “Seams” approach to story slicing. I could quickly help our team break down our work into manageable chunks. By doing this, we could then focus on conversations about where we would be trying to add value. 
Not only could I help our team look at a story from a capability perspective, but when it came to implementing a solution, I was able to slow the team down from jumping behind the first solution that made sense. Thus, slicing the story from a functional and technical perspective. This allowed us to instead, do something Intuit are renowned for; going broad before going narrow.
Following on from reading Eric Ries latest book, The Startup Way, I did some Google hunting for Intuit. They have this approach to ideas. Rather than getting behind a single approach, they spend time thinking up as many possible ways of solving a problem before going deep on just a few. From Neil’s session, I was able to initiate a level of discussion that didn’t end abruptly by everyone getting behind just one option. We took some time to consider alternatives, which in the end actually led to a completely different solution being implemented then was thought of beforehand. This has saved us a least a week of time if not more, as I’m confident, if we hadn’t considered as many options as possible, we would have been a week or more into building a solution, only to realise a better way! We found this better way much sooner, or at least our degree of confidence in the way we are building out the solution now is higher and ultimately more considered.
Inside of learning about functional and technical slicing, Neil taught us a technique he refers to as the Hamburger method. It’s a simple approach to functional and technical slicing. I won’t go into too much detail, as you can experience it first hand by attending a session(here), but it’s a great tool for getting your team to hold off on jumping straight into one solution and to consider a multitude of alternatives. 
Since this session, I’ve noticed an improved confidence to take a statement or vision that an executive has for their project, and slice it up. This will help our team to start looking at quick ways to deliver value. I have found in the past that getting the backlog into a healthy state has been hard. One of the specific problems I’ve faced is initiating a backlog and getting it to a point of being “ready” for a build. I’m not saying by any means I’m all of a sudden perfect. But the ability to slice has helped take a statement/assumption and show how we might leverage it to give the development team something to look at and work with. This, of course, has meant, we can more quickly establish our priorities and build something. The benefits for me are huge, it means we’ll be at a point sooner rather than later where our team can inspect and adapt what we are building. 
Thanks, Neil!

How Wasteful Are You?

Learnings on waste!
The concept of waste is something I have only recently started to learn. This is due in part to my immaturity in the software development world, in particular, my lack of on the ground agile software development experience, lean, SAFe, XP modern agile, etc…..I’ll freely admit, the concept of products in IT and product development is new for me, but an incredibly refreshing concept. Regardless, it is something that I find incredibly compelling and inspiring. The mere shift in mindset, from doing or managing a project to building a product has had an immense impact on me. Positive of course! Thanks @neilKillick.
Waste is something, I feel, I have let build in my projects in the past and no doubt my current. So, what is waste?
This blog, as with pretty much all my posts is an attempt at self-learning and in turn, share my insights with the few readers that take the time. I’m by no means making any progressive statements into waste that haven’t already been made.
The Toyota Production System(TPS) identified 7 major types of waste:
  1. Inventory
  2. Overproduction
  3. Extra processing
  4. Transportation
  5. Waiting
  6. Motion
  7. Defects
The Poppendieck’s later translated those for software development:
  1. Partially done work
  2. Extra features
  3. Relearning
  4. Handoffs
  5. Delays
  6. Task switching
  7. Defects
Essentially what waste is encouraging us to do, is look at the moment we get a customer requirement to the point when we deliver something of value back. And throughout this, we are reducing the time line by reducing waste.
1. Partially done work is wasteful, why? It’s a distraction! It’s something that keeps diluting our capacity to deeply focus on new work. It can lead to impacting the team’s rhythm, reducing confidence by not seeing the efforts of the team released as working software. A sign of partially done work might be too much currently “In-progress”. A number of features may sit waiting to be tested, all the while more work is being pulled in, potentially leading to a build-up of incomplete work, or partially done work.
2. Extra features can be wasteful, why? Are we not going above and beyond to deliver more value? From what I understand, extra features relates to Toyota’s “Overproduction”. It ties to ensuring what you build is what is needed. Extra features represent that last minute add-in to scope, the person with power or outspoken capability to push something across the line, just because the business “know” the customer needs it. This can happen even when there is little or no evidence to support its value. Extra features correlate to increased on-going expense/overhead. All features should be tested, maintained, tracked and off course, released to customers. There is an inherent cost in keeping a feature in customers hands regardless of whether it adds value or not, the value-add, of course, justifies the on-going expense to keep it. If something isn’t pulling its weight, why maintain it? Why distract your customers with it?
3. Relearning, seems to imply that there is little room to fail and learn from it, or as Samuel Beckett said:

“Ever tired. Ever Failed. No Matter. Try Again. Fail Again. Fail Better.”

However, when it comes to waste, relearning relates to all the things/overheads we do that don’t provide any direct value to our customers. They are pure overhead. Excessive documentation or laboured signoffs or change control forms or complicated risk registers. Relearning also talks about team member turnover. If you don’t care about your team, or as modern agile teaches us “Make people awesome” or they’ll leave/disengage, simple as that. Relearning waste can relate to time lost handing over to a new team member. Essentially knowledge is being relearnt due to the predecessor walking out the door.
Constant interruptions or multi-tasking, can this be relearning waste? Every-time you break from what Cal Newport refers to as deep work(amazing book by the way, link, go buy it!) it will take at least 15 minutes to “relearn” your way back up to your last point of progress. If you are constantly shifting between tasks, there is a lag time in getting up to speed, “oh, where did i last leave this?” This is something my manager is incredibly good at preventing. @TimTunbridge is always pushing to see whatever task is at hand through to completion, or at least as far into the “Done” zone as is in his control.
Documentation, the agile manifesto talks about interactions over documentation, put it doesn’t talk about no documentation. The relearning of the same knowledge is a bit of an achilles heel for me. At points when I’ve analysed, or understood something, worked on a solution/design, but haven’t clearly documented my progress. There is a number of wasteful actions here, I’ve left work that is partially done, and further to this, I’ll lose time in the rework/relearning, in order to get to my last point of progress. Understandable we don’t work in a vacuum, so we don’t have the luxury of seeing all work started through to completion. However, there is waste and it is much larger than it could be if quality documentation was adopted.
4. Handoffs! What the hell are they? It basically relates to a teams workflow. An analyst, pulls from the backlog, documents requirements, engages the business, gains their approval and all seems ready, and then they “throw it over the fence” to a designer, they put their 10 cents into it, who in turn “throws it over the fence” to an engineer! Something is built, now it must be “thrown over the fence” to a tester. Fundamentally, this, handing off approach is waterfall development, they are staging their work independently. What is the waste? The team is in a way playing a game of “Chinese whispers”, the features value gets lost or distorted by being passed around. It’s actually quiet astounding. Poppendiecks’s suggest 50% of knowledge/value is lost from every handoff. From Analyst(100%), to UX(50%), to engineer(25%) to tester(12.5%), 88% is essentially lost by the time it gets out the door to a customer!

88% is essentially lost by the time it gets out the door to a customer!

5. What about delays! This seems pretty apparent, right? It’s about closing gaps on the end to end process. The team gather customer insights, translate them into some form of requirements for a build and then capture feedback on that shipped feature. Spending large amount of project time documenting all the requirements, having large amounts of work in progress, thus encouraging partially done work, all lead to delays in getting work through to the customer. The Lean Startup talks about some of the initially things the author, Eric Ries does when consulting with a business. He essentially starts by limiting the amount of work in progress and putting constraints in place to prevent anyone within the team from pulling new work from the backlog. This is managed by setting up “WIP limits” –  WIP – work in progress, limit – only accepting a certain quantum of work to live in a state of progress, be it; “design”, “build” or “testing” as an example.
6. Task switching, surely an obvious point of waste. as i’ve said earlier in this post, every time you jump from task to task, you lose that time to re-familiarise with the task. Tying back to sprint planning in scrum, it is a regular point of complaint that so much time is lost in planning; “there is so much work today, I should waste time planning, just tell me what I’m doing”. Without a clear goal or set of goals, the chance of task switching grows, as does a lack of shippable features. A reduction in task switching, significantly increases focus, which should increase the likelihood to deliver some level of customer value much sooner.
A great example of this, is the agile gardener! On the weekends I like to get out into the garden, I mostly, just sweep, mow, whipper snip and weed, at the end I collect up all the debris or waste for the compost bin. Now, if we consider the process of preparation – getting the tools out and ready, doing the actual maintenance and the final task of collecting the debris and putting it in a bin. A traditional and seemingly efficient process would be to take all the tools out, then conduct all the maintenance, mow, sweep, weed, cut stuff, then collect the debris into piles and finally putting the waste or debris in a bin. What happens if something interrupts me at any point earlier than disposing into the bin? I’ve essentially delivered no value to my garden admirers(mostly my lovely wife). If I focus on each of my associated tasks in delivering the goal of a neat garden, I can reduce the risk of not tidying my garden, by completing each task rather than starting many of them at once. I might mow then put the grass waste in the bin. I might whipper snipper, and follow that by sweeping up the debris and putting it in the bin. I might then sweep the remaining general debris and put that in the bin. At each point of putting debris in the bin, I’m making valuable progress to a neat garden, because each task has a neatness value in of its self. Therefore I’m closer to continuously delivering value.
7. Defects! So, this is probably a pretty straightforward form of waste. If we commit to spending time building our product and as part of the process we are producing waste, we should be looking at ways of eliminating or reducing defects as much as possible. A defect can simply transpire to be some unideal state or transaction during the customer journey or it can be the heavy overhead of a demanding approval process. The Poppendieck’s have a formula which is:

Waste = (Impact of Defect)*(Time Defect Lies Undetected)

Essentially the longer you leave a defect in the product the greater the impact. I guess at a basic level, a defect with a low or minor impact might only cost $0.05, however, because the defect is minor, it’s not a smoking gun, and therefore is left, for maybe 4 or 5 months. Depending on the overlap of this defect, this could easily lead to 100’s of thousands, if not millions of dollars lost.
I hope you enjoyed my attempt to learn about waste. I’d love to hear your comments.

The Core Protocols and CheckIn

This is an extract from “Software for Your Head” – Jim and Michele McCarthy

We are fortunate as a project team to be sitting close by, shoulder to shoulder. Yet distance is always a central issue among collaborators and of course, the solution or remedy to distance is presence.
The primary task with any team is that of surmounting distance, the psychological distance or “Headgap”. As the size of the people in the team grows this headgap aggregates.
Team performance has less to do with the teams physical proximity, but with everyone’s degree of engagement with one another and our work.
A team using the CheckIn pattern and its associated protocols(there are 11) will be more aware of team presence than teams that don’t. A presence-sensitive team will be more likely to address and consequently surmount the challenges of a project. Presence-insensate teams will continue to address the wrong issues. Because presence trumps distance and distance is the enemy of collaboration, teams using CheckIn will prevail.
The CheckOut protocol allows an individual to take a break from the intense levels of productive engagement.
The Passer protocol serves as a safety valve for the entirety of the core protocols. It allows for anyone to decline to participate without being questioned by other team members.
Why do we need to share our emotions, why can’t we just have a beer or lunch?
A large percentage of people believe that expressing emotion at work is inappropriate or unprofessional, so they maintain an emotional facade, usually presenting a diminished emotional effect. When emotions are expressed indirectly at work, the distance between people increases. Emotional self-repression reduces both team efficiency and product quality. When you hide behind any kind of facade, you are necessarily less present than you could be, and that intentional ambiguity, made of human energy. Any awareness that you exercise is usually required to monitor the layers more completely and/or to build up the facade even more.
You CheckIn to benefit yourself. It is the first step along a team’s path to a more effective and enjoyable life. It is the first thing to learn. It is also the last thing to be mastered.
The benefits you will realise include
  1. Increased self – awareness
  2. Greater capacity for engagement
  3. More time
The Protocol
It’s a commitment to be present.
  1. Each person takes a turn when he feels it is appropriate until everone is “in” or has “passed”
  2. Each person says “I pass” or “I feel [sad and/or mad, and/or glad, and/or afraid]”.
    1. It is optional to give an explanation
  3. Say “I’m in” this statement seals your commitment
  4. The group responds, “Welcome” to acknowledge that they heard your CheckIn and accept your commitment.
Person checking in:
Team Member: “I feel afraid and glad and sad. I feel afraid that this new project won’t be exciting or that it won’t turn out well. But I feel glad that we are starting a new project. Also, I feel sad that I’m not with my family today. And I’m in
Team: “Welcome”
The Core Protocols
  1. Pass – Used to decline to participate in something, use it anytime
  2. CheckIn – Used to begin meetings or anytime an individual or group see it adding value(explained below)
  3. CheckOut – This signifies that your physical presence always signifies your engagement. You must CheckOut when you are aware that you cannot maintain the Core Commitments or if it would be better if you were elsewhere
  4. Ask For Help – Use it to efficiently make use of the skills and knowledge of others.
  5. Protocol check – Use protocol check when you believe a protocol is being used incorrectly
  6. Intent Check – To clarify the purpose of your own or another’s behaviour
  7. Decider – Use anytime you want to move a group immediately and unanimously towards results
  8. Resolution – When a decider vote yields a small minority of outliers, the proposer quickly leads the team, in a highly structured fashion, to deal with the outliers. The resolution protocol promotes forward momentum by focusing on bringing outlines in at least cost.
  9. Perfection Game – This protocol will support you in your desire to aggregate the best idea’s. Use it whenever you desire to improve something you’ve created.
  10. Personal alignment – This protocol helps dive deeply into your desires and find what’s blocking you from getting what you want. Use it to discover, articulate, and achieve what you want. The quality of your alignment will be equal to the quality of your results.
  11. Investigate – Allow you to learn about something that occurs in someone else. Use it when an idea or behaviour someone is presenting seems poor, confusing, or simply interesting.
The Core Commitments
  1.  I commit to engage when present
  1. I will seek to perceive more than I seek to be perceived
  2. I will use teams, especially when undertaking difficult tasks
  3. I will speak always and only when I believe it will improve the general results/effort ratio
  4. I will offer and accept only rational, results-oriented behaviour and communication
  5. I will disengage from less productive situations
  6. I will do now what must be done eventually and can effectively be done now
  7. I will seek to move forward toward a particular goal, by biasing my behaviour toward action
  8. I will use the Core Protocols or better when applicable
  9. I will neither harm, nor tolerate the harming of anyone for his or her fidelity to these commitments
  10. I will never do anything dumb on purpose

Welcome The Distraction – Fold With The Crease

The title is not exactly the conclusive statement it perhaps sounds. I’m all for planning and taking on a proactive approach, embracing alive time over dead time, as Robert Greene describes it; dead time, a time when people are passive and waiting while alive time, is a time when people are growing, pushing, learning, experimenting.
There is something to be said for welcoming the distraction. The stoics might refer to it as Amor Fati, the power or self-control that you can foster in life for accepting your fate, to embrace rather than fight, to fold with the creases of life and cease resistance.
Robert Greene is somewhat a hero of mine, although one from afar, needless to say, I like his work(Robert Greene Mastery). He and 50 cent produced a book called the 50th law, there is a passage that struck me, which talks to folding with the creases:
“Events in life are not negative or positive. They are completely neutral. The universe does not care about your fate; it is indifferent to the violence that may hit you. Things merely happen to you. It is your mind that chooses to interpret them as negative or positive” – Robert Greene, Curtis Jackson
It is all too easy for me to sit and complain about various things that come across my desk in any given day. But what use does this fill? Is my time well spent on the act of exploiting my frustrations, is anyone’s time well spent in this pursuit? Perhaps there is a fine line between venting and whining. I’m not really clear on the difference, perhaps a vent is something to hide behind, who knows? I don’t.
Moreover, I’ve been faced with a number of negotiations that test my resolve. Part of me feels a need to retreat and incubate my team and create a more controlled environment where we can have greater input on the influences over the project, but the reality is that we all need each other, in various forms. A need to remain open-minded, and welcome the distraction is a necessary part of life, work and project management.
“There are no perfect ‘worlds’ we must”, as Marcus Aurelius the last of the great Roman emperors would say “welcome with affection what is sent by fate”. “A good person is a person who is satisfied by that which nature assigns him or her”, I’ll make more of an effort to fold with the crease and accordingly be a good person and remain open.
All is an opportunity. Welcome the distraction!

How Tired Are You?

I’ve received various advice over the years regarding success and just generating progress in life(broad, I know). One thing I’ve heard regularly over the years is the concept, of not to just work hard, but to work smart! Mostly this statement pisses me off. When I heard this, I felt like I was doing something wrong, like I had taken a massive wrong turn in the journey of life! I felt naive, it took me off guard. I was completely unaware that instead of working hard, one could work smart and still achieve all that good stuff. It’s somewhat like the advice of following your passion, which is utter drivel(reference Cal Newport and Ryan Holiday)!
The notion of working smarter first hit me when I was about 13, I had the end of year school exams ahead and I was working hard, completely unaware of the alternative, this concept of not working hard, but working smart. And I got criticised for working too hard, for spending too many hours studying, that I shouldn’t need to, that it’s “not about working hard, it’s about working smart”. This disastrous advice, thrown into an impressionable little teenagers head sent me down a rabbit hole that would, unfortunately, take me close to 20 years to climb out of(17 years to be exact).
My hypothesis toward the work smarter concept seemed to be associated with less time, less effort but ultimately, all the glory. Of course, the whole approach is predicated on knowing what to focus on, what to prioritise, and as if, by acknowledging, that “I work smart” not hard, the person above, god himself would pass down a roadmap on what I should focus on and what I should ignore. That never happened, however, at times I still wait in hope!
I get that some can work more efficiently, but I believe this is because they(the masterful few), have, over the years built up a foundation of understanding and insight that allows them to progress quicker, and only possible after usually years of laying the “ground-work”. An accountant, for example, will more quickly come up to speed with changes in the income tax thresholds, then I will. If I want to have the same level of understanding, I may have to put in two to three times the effort. It’s along the lines of what I wrote about in a not so recent post of the not knowing notebook technique that Richard Feynman employed(Growing Pains). If my not knowing notebook is bloody huge, then it’s simple, I will need to schedule a significant time to understand the topic then someone with a smaller not knowing notebook.
I get there are some predispositions that enable certain people to acquire new knowledge much faster than I. But it’s this predisposition, this nature versus nurture bias, that talent is key. The talented few that we look to as role models, when in fact, I feel they are the exception, not the benchmark I want to model from.
I feel the work smarter brigade make the assumption that what you are doing is repeatable, that you can learn from one activity or task, and accordingly next time round work “smart” and get it done quicker. However, as with most things, I find circumstances change, very few things that are worth doing are truly repeatable. So a level of work hard seems to be constant.
“There’s no talent here, this is hard work. This is an obsession. Talent does not exist, we are all equals as human beings. You could be anyone if you put in the time.”
    Conor McGregor

Growing Pains

I’ve recently been reading up on Richard Feynman and watched a number of his lectures hosted by Microsoft. Bill Gates is a big fan and at some point, he came across a great lecture series of Richard Feynman’s(click here). Thankfully he’s made them publicly available through  Microsoft website.
From what I have read, the source is questionable, but Richard did not have the typical noble prize winning crazy high IQ. Which, is now a blessing for anyone who has an interest in self-development, as he had a number of famous methods employed to better understand a topic. From what I have read, he was clearly a very hard working, charismatic and disciplined individual.
One of the “techniques” he regularly employed was utilising a notebook to record all the topics, sub-topics and generally, things he didn’t know or understand. He furthered this process when learning a challenging topic, like Quantum Mechanics with his deliberate and brilliant process of simplification, he would continuously re-visit what he didn’t know about a topic and update his notebook overtime.
This is something I have been working on. Frequently I come across things I know little about but feel I should. At the moment I’m finishing up writing a business case for a Digital Customer Engagement project I’m lucky enough to be leading. Concerningly, my “I don’t know” note which I keep in Evernote, was getting larger and larger, given I need the paperwork ready soon, I’m somewhat relieved as I start to get more and more across the document. Mind you, this is mainly due to the great support I receive from the projects team I’m part of.
Through this process, I’ve started to see this large list as a good thing, almost like a marker that I can re-visit and track my understanding. A few weeks ago, if I was to sit down and detail what I don’t know about writing a business case it would have been very brief. A one-liner, simply and broadly stating “I don’t know where to begin”. Now after a little while on the topic, the areas I don’t know about are starting(emphasis on starting) to become more specific. I figure as you tackle a new topic, process, concept, theorem or in my case, a business case the more specific your “don’t knows” become, the further you’re probably progressing.
Unconscious incompetence, conscious incompetence, conscious competence, unconscious competence( Abraham Maslow – thank you, Katie). The Maslow framework springs to mind, in helping me understand the process, to some extent that I’m going through. A few days ago, I had no idea what I didn’t know. Now, I’m becoming more and more familiar with what I don’t know. If I was to offer some emotion around this point, I would feel right now, as I build a big list of what I don’t know,  is the scariest point. It can become overwhelming, and usually the point wherein you have to dig your heels in and fight to make progress. My mind is constantly trying to pull me out of this discomfort, as it’s a process that highlights how much I don’t know, so why not send an email, check twitter or jump on Instagram. I can do that, I’ve done emails before and checking social media is child’s play, I know how to. As much as I try to distract myself and protect my little ego in the moments of unknowing, it’s not going to get my business case done.
I would stagger a guess that this heightened discomfort, would commonly be the point where most get discouraged and make some attempt to not go any further. This is where Jack Dorsey or Mark Zuckerberg start sitting on my shoulder, reminding me how fun it would be to just check out some social channels. If they win, it can snowball into one hell of an unproductive period, and potentially worse, make a crap of my day.
Why is mindfulness important, because it’s at this point, I’ve found, I need to be the most self-aware I can be, to fight the urge to slouch, and muster some grit to fight for some tiny bit of progress. I’m sure reading/watching the latest hilarious act some cat has done would be fun, but it won’t give me much in the long term.
The stoic philosopher Epictetus comes to mind here:
“In life our first job is this, to divide and distinguish things into two categories: externals I cannot control, but the choices I make with regard to them I do control. Where will I find good and bad? In me, in my choices.” – Epictetus 

New Horizon

It’s been some time since I’ve had a clear path forward. From March 2017 until the end of August I’ve been working in my first Government position but only in an Acting capacity. The role has been interesting, having a team and in particular not having a project of my own. It has been a big learning experience, working for others rather than a project, offering where I could, some of my insights and prior experience to help. Some have been really appreciative, others not so much. Part of me feels I failed somewhat, for not creating a noticeable legacy. Another part of me feels I set things up so I could transition into my new role, overall I’m still not clear how I’m leaving that position.
My new job is excitedly the best role I’ve ever had, the potential is huge. I’m truly fortunate, I get to step back into the project world, working under an experienced highly accomplished project manager, now program manager, it’s my first project manager role in a truly agile delivery, and needless to say, I’m super pumped.
How can I say we are truly agile? Since mid-June, I have been on the job market, knowing the acting role would come to an end and not knowing that transitioning across to a project management role within Parks Victoria was possible, so I was all over seek.com.au. I was, of course, wrong and am indebted to Tim Tunbridge, Neale Tayler and Jen Rebeiro for making it happen. However, I digress, through the process of hunting for a job and discovering yet again “agile” is a hot topic, but still realising from an I.T. project management perspective mostly/largely misunderstood. A number of companies and jobs have talked to an “agile” environment, but probing a little deeper, discovering a traditional culture still prevails when it comes to projects.
In tech projects, a traditional approach would be referred to as a “waterfall” method, Prince2 and PMBOK are renowned methods in this type of delivery. Basically, waterfall lays out the work of a project sequentially(mostly), wherein; scope, time and money are fixed, but consequentially quality is variable. Agile is by-enlarge seen as the way projects should be operated, but when you start to get a feel for whether or not scope is variable, as would be the case in a truly agile project, companies, supervisors, program managers get highly uncomfortable.
Part of me understands that as project delivery goes, you must inform the business on what you will do, but there is a distinction that needs to be made here. Ideally a team would talk about requirements with an asterisk next to it, something along the lines of “we are not able to predict the future, however, from our analysis we believe addressing these organisational problems will return value to the business and we believe we can get X amount of work done in X amount of time. However, as we progress we will learn more and re-assess what we have delivered against our initial thinking and how much we have spent. From here we can make an informed decision on how we progress and even whether the project is still viable.
During my formal education(albeit a one week course, I’m an expert now!!!) on agile project management (DSDM), I was blown away by the concept that during a project, at key releases/milestones, the project control board, would actual re-assess whether it was worth continuing. This can often, at least at first, seem like a negative thing, but it ties back to Pareto’s 80/20 principle. With functional releases of a project you will realise benefits along the lifecycle of the project, but there very well could be a point wherein 80% of the benefits are realised and the remaining 20% is likely to have less of an impact. At this point, it’s potentially worth considering if that money required to deliver the remaining 20% is worth it, or perhaps better utilised re-investing into anther project that might have a greater impact with the same money.
Coming back to my earlier point. We are in an agile world now, wherein scope is variable, time is fixed, cost is fixed and quality is fixed. Other organisations and projects are possibly impeding their success before even beginning by fixing every aspect of a project. Lately, I’ve thought about it like quadratic equations, solving for X, while all your other elements are unknown
Even though based on the elements of the equation, we can assess what X is worth relative to the other we don’t come away with a distinct value. You could say the quality of our answer is compromised as it is dependent on others. A project, I believe must have distinct benefits, independent of others.
I’m not naive to think there will not be challenges ahead, however, at least I know that there is hope to deliver something great without compromising quality. I.T. has an extraordinary poor delivery record, (RE: Standish report “CHOAS), some 16% of all IT projects deliver, all the others fail in some manner. I’m hoping to work hard and diligently to be in that 16%.


In late July of this year, 2017, The Australia and New Zealand School of Government website won an award, a gold award for design.
This new website was a project I was responsible for, one I was hired, as a contractor to project manage.
The award was given to Butterfly, a company, through research online, I found and approached. This talented digital agency was one of many “vendors” I had found and approached to bid for the job of developing a new website for The Australia New Zealand School of Government. Through an evaluation process that I am very proud of, the organisation came to the conclusion that Butterfly were the strongest vendor.
Hands down, they were a great partner to have and the end result was very pleasing.
When the award came out, there was no recognition, of my work. Butterfly were acknowledged as the winners, and the organisation as the benefactors. I didn’t receive a call from my former client to share in the spoils. The exact opposite, I heard nothing from them. I got to watch from afar as The Australia and New Zealand School of Government thanked Butterfly for their great work and vice versa. A kind team member inside of Butterfly made me aware of the award, from there I took it upon myself to make any friends and colleagues aware of this award by social media. And of course, my proud wife was quick to jump on social media and highlight this award and link it to me. Which I’m grateful for.
Some part of me is saddened, I gave upwards of of 16 hours of my day at times to this project, sacrificing time with my family, forgoing a level of sanity due to sleep deprivation in order to keep the project moving forward. Yet, I know, I shouldn’t need the acknowledgement of its success. I don’t need to sit in its spoils, but part of me wanted it.
I’m a fan of stoic philosophy and trying to implement this philosophy as a means to operate on a daily basis. I’m far from performing in a manner comparable to Stockdale or Epictetus. This moment, what some philosophers might call a moment of truth, I can say I failed. I craved the notoriety.
I’m writing this, not as a winning, but as an exercise in awareness. The discipline of writing, forces me to concisely understand my inner workings, and in this case, my inner failings.
I’ll leave with a quote from the ultimate teacher in self development, Marcus Aurelius
Tranquility…comes when you stop caring what they say. Or think, or do. Only what you do.”