Managing People, Expectations, Goals and having fun doing it

As most folks at work who’d care to weigh in would tell you, I am not particularly into organising, well, anything — its just too high-level for me, and I ‘d rather avoid situations where I am called in to tell people what to do, even if it’s the right thing, all things considered. (wow, this is a looong sentence).

On a personal level, this is not the case, at least insofar my notes, thoughts, bookmarks, whatever, is concerned. I maintain many dozens of files, from films and books I ‘d like to watch and read, to programming tips and findings, to ideas for future applications and services, you name it. I use Dropbox to store all those (mostly plain text and markdown documents) and thanks to Spotlight, everything is a cmd-space, input, enter away.

Spotlight is my favourite OSX feature. Ever since it was introduced with OSX 10.4 Tiger, I have been relying on it to find and open everything. The search operators are very handy.

But I digress. I wanted to dump my thoughts and recommendations, mostly watching from the sidelines and not really having any hands-on experience on there, with managing projects and people. Those should fall squarely in the common-sense spectrum and are by no means revolutionary.

Short-term goals and deliverables
Tame your expectations. You want to build the next X? and you want it to be better than X? great — however, you are likely off by orders of magnitude in your efforts, time and cost estimates.

You almost definitely can’t do it in 5 months. Conversely, you almost definitely do not want to do it in 5 years.
If your estimate is too low, you will introduce pressure to your team and as you approach that milestone date, despair and realisation will set it. What to do now?
If your estimate is too high (5 years!), you risk losing track of what’s going on. Your engineers will have to move to other projects, new ones will join, and what’s even worse, the longer the timespan, the more the chances for folks to weigh in with their ideas(or, demands) thereby forcing more meetings and changes of goals and processes.

Do not plan ahead for months. Accept feedback and requirements from your coworkers, especially those key coworkers. You need to enqueue and prioritise though. You need to make forward progress and strive to deliver often, even if that means you will not please everyone. Progress is everything.

Do not go from 0 to 8. Go from 0 to 1. It will take way less time to get there, the chances of actually getting there are higher, the potential for others to affect the progress is much lower(proportional to the time it takes to get to that next step), and succeeding in your milestone/goal will motivate everyone and make them feel confident in your collective ability to make it to the grand goal.

Review often. Every week, perhaps, and always when you reach a milestone (next incremental release, next major feature, anything). Reviews are vital. They give you a chance to identify problems in a timely fashion, drop things that clearly don’t work and/or will impact progress severely, or even add new small features for the next milestone based on the progress so far. Steping in in time to deal with an issue before it escalates into a major one, is a great benefit of short-span steps and reviews.

Consider MVP(minimum viable product) theory, especially if its obvious that you are not making progress. However, keep in mind that, depending on the market you are competing in, you may not have that option.

No matter what though, do NOT break things. Facebook’s ‘move fast and break things’ motto was retired, because they too figured out breaking things is not an option, even if you use ‘BETA’ in your product title somewhere.
People have little to zero tolerance for problems, especially true nowadays. Getting anyone to try your product is really difficult. They will likely come back even if your product is not fully baked in terms of features-set, especially if it it does them well, but its unlikely they will come back if anything they try doesn’t work or downright breaks the service/product. Making sure milestones are easily attainable and changes introduced are few
so that you can make sure they are well tested helps here.

Andrew Stanton at Pixar (from the excellent Creativity, Inc. by Ed Catmull):

Moving fast forward allows the team you are leading to feel like, ‘Oh, I am on a boat that is actually going towards land.’. As opposed to having a leader who says ‘I am still not sure. I’m going to look at the map a little bit more, and we’re just going to float here, and all of you can stop rowing until I figure this out’. ‘And then weeks go by, and morale plummets, and failure becomes self-fullfilling. People begin to treat the captain with doubt and trepidation. Even if their doubts aren’t fully justified, you’ve become what they see you as because of your inability to move.

There are more relevant quotes in the same book that applies in this problem. Another one, again by Andrew Straton:

In a battle, if you’re faced with two hills and you’re unsure which ones to attach, the right course of action is to hurry up and choose. If you find out it’s the wrong hill, turn around and attack the other one.

Accept Change
Do not spend time in elaborate specs and design documents. It’s a waste of effort and time. High level goals are useful, down-to-last-detail task descriptions and ways to accomplish them, are not.

Furthermore, it’s natural for projects to require changes — perhaps because it actually makes sense, or because an important business decision was made, or because new technology were made available. Do not resist change.
You need to consider the costs of change though, and communicate it to key people, clearly, if they are the ones who ultimately need to make the call of change. Progress is everything. Don’t chase the cool-hot-tech trends, be programatic.

Make the most out of the Journey
As you move from one step to the next, you become better aware of every person’s skills and mindset, and you are getting better at making estimates based on past calls and how close to the mark they were. It’s not unlike training a ML/AI model, where the more data you feed into it, the more training passes/runs you execute, the better the model becomes.

Project Post-mortems
So you shipped your product. Congratulations!. Take a time to celebrate before you move on to the next iteration. When you are done celebrating, you may want to review the processes involved, decisions made, tools used. In other words:

What Worked and what Didn’t, and How can We do Better
Did choosing X over Y help the project, or harm it? Did rewriting something because ‘it made sense’ was really the right call? How about adjusting goals and expectations thereby delaying release by many weeks or months?
Now that’s its done, you can score your collective decisions and actions. This will be very valuable for you can identify mistakes and great strategies. If you have made a mistake and you become aware of it, you have no good excuse to repeat it. So, identifying all bad calls and mistakes you have made will hopefully result in them never coming up again in future work.

Good luck — though ideally you won’t have to rely on that to make things work.

This last quote by Ed Catmul is great for wrapping this up:

Self-interest guides opposition to change, but lack of self-awareness fuels it even more. Once you master any system, you typically become blind to its flaws; even if you can see them, they appear far too complex and interwined to consider changing. But to remain blind is to risk becoming the music industry, in which self-interest(trying to protect short-term gains) trumped self-awareness(few people realized that the old system was about to be overtaken altogether).