Over the past week, I have doubled my readership; I now have two subscribers. Assuming I can keep this up, I should have readership in Alpha Centauri before too long. Thanks to both of you. If anything you find is interesting, pass it on. I’ll try to make these more concise.
Note: Hey World allows me to decide whether to email my subscribers. I will post articles without sending a notice to avoid flooding inboxes.
I take in a lot of content, dozens of hours of YouTube video and a couple thousand blog posts. Of that content, perhaps a quarter to third relates to my professional interests of technology management and independent author. Maybe four percent of all this content is insightful after 23 years of pursuing both endeavors. Rather than throw up a blog post for each morsel, I plan to write a weekly summary. This is Week 24 of 2021. Each of the three observations are YouTube videos by Dave Farley of Continuous Deliver that are much richer in meaning than my summary.
Note: Hey World allows me to decide whether to email my subscribers. I will post articles without sending a notice to avoid flooding inboxes.
I take in a lot of content, dozens of hours of YouTube video and a couple thousand blog posts. Of that content, perhaps a quarter to third relates to my professional interests of technology management and independent author. Maybe four percent of all this content is insightful after 23 years of pursuing both endeavors. Rather than throw up a blog post for each morsel, I plan to write a weekly summary. This is Week 24 of 2021. Each of the three observations are YouTube videos by Dave Farley of Continuous Deliver that are much richer in meaning than my summary.
- Bad Software Engineering observes you cannot fix Schedule and Scope.
- Guide to Managing Technical Teams helps technicians learn to be good managers
- Start a New Software Project talks about accepting your ignorance and disproving your assumptions until you get to a solid solution.
Bad Software Engineering
In Bad Software Engineering, Farley uses Cyberpunk 2077's failed rollout to expose poor technology management. Game development is among the most regressive in terms of technology management by its adherence to waterfall. Maybe your company has them beat? Bad management fixes scope and schedule: “we will deliver this major new capability by the end of the next fiscal year.” Human nature underestimates by a factor of two or four. Executives insist on impossible schedules to address competitive pressure. In the PM Iron Triangle (Scope, Schedule, Resources), he observes the idea of adding resources was dismissed forty years ago...so the triangle is only Scope & Schedule. Therefore, you cannot fix both Scope & Schedule.
I think we should consider Scope & Schedule to be along a continuum, but by the end of this article I am probably wrong.
I think we should consider Scope & Schedule to be along a continuum, but by the end of this article I am probably wrong.
Guide to Managing Technical Teams
In Guide to Managing Technical Teams, Farley focuses on the role of a Technology Manager as team captain. Competent technicians grow servant-leadership skills to effective managers. Technicians expect the team to do things their way, expect perfectionism and expect that they have to be the best on the team. “Recruit people smarter than yourself” is a business proverb that tries to erode young manager attitudes.
Technical managers are coaches; party hosts. Outstanding leaders maximize the team’s performance by removing impediments and enhancing their creativity. They foster cross-organizational collaboration and pursue a sense of common ownership. Micromanagers are bottlenecks, caustic to morale and cannot develop more junior personnel. Managers by Remote Control tell the team how to solve a problem rather than help them frame the problem, or imposing specific standards on how to design or code or write, either via the design or the code review. Scaled Agile Framework’s advice on using Ishikawa during Inspect & Adapt embodies the “teach the team to fish” behavior that counters the “Remote Control” anti-pattern.
Good leaders still establish guide rails to ensure fundamentals of quality and security are followed and accept the team’s “good enough” over their personal idea of perfection. They have strong opinions, but hold them lightly. Farley uses consensus-based decision making to let the team have that ownership. This is Amazon’s 13th Leadership Principle “Disagree and Commit.” I’ve witnessed Technicians get to the executive level without becoming effective leaders.
Technical managers are coaches; party hosts. Outstanding leaders maximize the team’s performance by removing impediments and enhancing their creativity. They foster cross-organizational collaboration and pursue a sense of common ownership. Micromanagers are bottlenecks, caustic to morale and cannot develop more junior personnel. Managers by Remote Control tell the team how to solve a problem rather than help them frame the problem, or imposing specific standards on how to design or code or write, either via the design or the code review. Scaled Agile Framework’s advice on using Ishikawa during Inspect & Adapt embodies the “teach the team to fish” behavior that counters the “Remote Control” anti-pattern.
Good leaders still establish guide rails to ensure fundamentals of quality and security are followed and accept the team’s “good enough” over their personal idea of perfection. They have strong opinions, but hold them lightly. Farley uses consensus-based decision making to let the team have that ownership. This is Amazon’s 13th Leadership Principle “Disagree and Commit.” I’ve witnessed Technicians get to the executive level without becoming effective leaders.
Starting New Software Technical Projects
Farley discusses Starting a New Software Project and the hubris of thinking you understand the problem and the approach. If you did, you would clone what already worked. Prefer to not trust yourself.
At the video's end, he emphasized the importance of having a lightly held vision of how you are making your customer's lives better. Use rapid releases to customers to validate or adjust the vision, and use the vision to confirm the development is on track. Avoid estimates in deference of imagining how you make your users lives better if you met that vision. Avoid detailed planning because you are learning. If certain features are required, fix the scope (not duration). If you must deliver by a certain date, do not fix the scope.
- Assume you are wrong in every assumption, which is consistent with The Lean Startup philosophy about testing business assumptions. Find the fastest way to disprove your assumption.
- Decide late, using validated learning. He agrees with A Seat at the Table: IT Leadership... that you should defer decisions until the last reasonable moment. This requires you work in ways that limit the harm of mistakes, which requires smaller steps.
- Define Defensively via “good enough” implementations that allow you to learn and evolve, and a good test suite (like Behavior Driven Development) to help you find and fix problems. This includes frequent retrospective Inspect & Adapt
- The best way to validate your assumptions is to get the skeleton of a production product in the hands of its users, then increment based on feedback. This is the Minimum Viable Product approach. In The Startup Way, author Eric Reis demonstrated this approach with a diesel engine that successfully affected General Electric's vision of delivering a multi-environment, efficient engine that would make them a billion dollars in year 5.
--
Ben
In tenebris solus sto