This past weekend, I was excited to see that the cosmonauts on the Space Station were commemorating Yuri Gagarin’s flight into space with a special Slow Scan Television (SSTV) broadcast. I hadn’t set up the antenna since we moved into our new home, so I took this as the perfect opportunity to do so.
I managed to capture five images over the three days. The carrier was quite strong, but the modulated signal level was very low until the last day. And then I was able to capture a proper image:
One of these days I will have to invest in a proper rotator. Got a little wet running out into the rain to track the station. Antenna is an Arrow II Satellite Antenna:
Here are the other images I captured (all images captured using Black Cat Systems SSTV iOS App and a YAESU FT-7800):
An (overly) ambitious title for the post notwithstanding, Simon Dowling offers a fair number of actionable insights on this quick read on the Venturi Group blog, including this:
As a CTO you are not there just to further your own agenda, not to just ‘look good’, but to drive the company forward as a whole. You are the single person others look to for decisions on short-term, tactical matters as well as plans for long-term, strategic goals.
Nobody is perfect. And trying to be perfect is not your job. Your job is to make informed decisions using the information at hand. Or in cases where there isn’t enough information, to set about collecting more so that a decision can be made….
….the easiest way to train this skill is to be forced to make these kinds of decisions in front of others.
By the end of the project, we had done more than we probably needed to. Honestly, _far_ more than we needed to. The requirement had come down to build “Service X”, and the team rallied and pulled it off. But, in hindsight, I think we might have been able to deliver sooner – if I had put more effort into clarifying what success looked like for our stakeholders, and been more ruthless about stripping down the service to the bare essentials to meet that yardstick.
In a way, it is like that part of The Martian (a great book and a good movie) where the main character, marooned astronaut Mark Watney, has to strip everything he can from the sole surviving Mars Ascent Vehicle (MAV) in order to meet his rescuers high above the red planet. The weight of things like the hatch, chairs, dashboards, and nose cone of the MAV were so heavy that it limited the altitude the MAV could reach. Success (getting Mark off the red planet) was not going to be achieved with all that excess weight.
Engineering leads and managers face a similar situation frequently. Projects assigned to their teams are often not accompanied by a lot of clarity around what success looks like. A lot of assumptions end up being made unnecessarily. The success yardstick might be assumed to be a fully functioning, pressurized, climate controlled MAV with comfortable seating and spare spacesuits, when the actual success yardstick might simply be a means of getting a marooned astronaut into high orbit.
It comes down to engineering leads and managers to always be clarifying – to always be asking their stakeholders “Why?” – and to always be jettisoning (or at least postponing) unneeded weight – the earlier in the project the better.
We should always be asking:
Why do we want to launch product or service X? And then ask why again. Unpack the why’s a few times. “Because the CEO said so” isn’t good enough. They have a “Why” too.
What does success look like? What sorts of customers do we want to attract?
What are we assuming about our customers’ mindsets? Where are we trying to read their minds without actually asking them what matters to them? Hint: your ability to read your customers’ minds is far, far weaker than you realize.
What stakeholder requirements are based on their own assumptions (or worse, mind-reading) versus stakeholder requirements that are backed by validated insights? Drive stakeholders to back up their requirements with facts and data.
What is the bare minimum our customers need? Do we really need to be able to provide multiple levels of service? Is there one level that we can start with first? OK, now ask again – within that level of service is there even more we can jettison? Repeat this often.
How much time do we have? Why did you pick that deadline? What are the other events you’re trying to tie this product or service’s launch with
How much money does this need to make in the first year? The second? What support costs are acceptable? Does everything we are doing support that? Why or why not? What can we jettison to reduce support costs?
What customer acquisition cost is too high? What minimum long term value is expected? How soon must that value be realized? This can also help engineering get a sense of which features/services need to be streamlined and prioritized or written at all.
How much flexibility or scalability does the system really need to support right now? Where are the requirements unclear, and where can we somewhat safely assume things are less likely to change? Over-engineering flexibility is expensive and slows velocity.
How many new customers does this need to generate for us? What rate of churn is too high?
What key metrics are needed to know if everything is meeting expectations?
Essentially, always be clarifying what success looks like. What the yardstick is.
What questions would you add to your repertoire when it comes to clarifying success with stakeholders and jettisoning unneeded scope? Where might you have excess weight on your project that is keeping you from the best velocity towards that first (or next) release? Where have you, your team or your stakeholders assumed complexity where it is unwarranted and doesn’t meet anyone’s actual yardsticks? What unessential effort is going to make the project possibly miss some critical rendezvous?
Props to Jeff for the constructive feedback that sparked this post.