技术问题很少长期存在。
一个平台可能需要规模化。
产品可能需要更快移动.
一个组织可能想要引入AI,使老旧的地产现代化,改善客户经验或推出全新的东西.
第一种本能通常是看技术本身.
哪个建筑应该改变?
我们该买哪个平台?
哪支队伍应该建?
我们应该介绍哪些工具?
这些问题很重要。
但它们往往不是决定结果的问题。
在Cralgo,一种模式在技术工作中不断出现:更难的是技术周围的系统。
问题背后的问题是考虑一个似乎有执行问题的方案。
送货很慢 优先事项不断改变。
各队意见不一.
一再重新作出决定。
地平线在继续移动 很容易得出结论,工程团队需要变快.
但仔细看看,制约可能在于别的地方:所有权不明确;优先事项并非真正定级;产品和技术根据不同的假设运作;建筑决策是在没有商业背景的情况下作出的;团队执行任务时不了解背后的判断;治理存在,但只是作为报告;关键决定仍然依赖少数人。
这些都不是纯粹的技术问题。
这些问题涉及判断、所有权、能力、顺序和治理。
技术只是让他们可见。
更好的技术不会自动产生更好的执行 组织可以理解地大量投资于平台,云,数据,自动化和AI.
但技术只有在其周围的组织能够很好地利用这种能力时才能提高能力。
一个新的平台不能决定什么是优先事项。
新的操作模型图不能创建所有权 。
仪表板不能取代判断。
大赦国际无法解决一个组织本身不了解的模糊问题。
而更强大的工程团队不能无限期地弥补上游决策不力.
这在组织规模上更为重要。
在较小的公司中,背景旅行是非正式的。
创始人和高级领导人接近于决策.
人们理解为什么有些事情很重要,因为他们在作出决定时在场。
随着组织的发展,这种背景开始分崩离析。
更多队伍参加.
更多层层出现.
出现了更多的依赖关系。
引进了更多的专家能力。
本组织增强了能力,但同时可能丧失判断的连续性。
判决的初衷会随着执行而削弱。
缺失的地层往往是相通的 这就是为什么一些最有用的技术工作发生在常规类别之间。
战略与执行之间.
在商业野心和建筑之间 介于产品与工程之间.
在领导决策与什么团队实际执行之间.
在一项被批准的倡议和该组织有能力执行的倡议之间。
这个连接层很难命名,因为它不是一个单一的函数.
有时看起来像是技术策略.
时有相入为治.
有时它需要操作模型,英才中心,交付舱,架构干预或高级执行能力.
形式随问题而变化.
根本问题不在于:本组织如何在执行过程中始终作出正确的判断?
从决定开始,而不是从解决办法开始。
处理复杂技术情况的有用方法是暂时抵制解决办法语言。
在询问需要哪个平台,架构或团队之前,问:我们到底在试图改变什么?
现在有什么关系?
在我们改变时,必须保持什么稳定?
哪些决定尚未解决?
这些决定由谁真正作出?
缺少什么能力?
执行取决于何处