早期工程师的不幸遭遇

2022-02-17 10:29:29

登录表单下方的红色文本为";意外错误" 我正从一位名叫埃里克的技术支持人员的身后看过去,他刚刚第一次尝试登录我们的产品。他的隔间看起来和房间里其他大约80个分散的隔间一模一样,只是办公桌上有一个定制的机械键盘,上面有没有标记的键帽和霓虹灯背光。我们';我一直过得很好,但现在他回头看着我,脸上露出背叛的表情,告诉我他在想什么:“请告诉我,你没有浪费我整个周六的时间。”

我转过身,感觉自己喉咙发紧,因为我看到房间里到处都是同样的错误信息,他的同事们开始困惑地抬起头来。

2018年,休斯顿的一个闷热的周六上午,我在一家It管理服务提供商(MSP)的网络运营中心工作。MSP将IT作为一项服务来管理其他业务——从域和网站、电子邮件和云服务,到安全运营和网络基础设施。

这家公司是我们最早的客户之一,也是迄今为止最大的客户之一。我们';d为他们的支持团队组织了一次周末培训课程,学习如何使用我们的初创公司&39;s的web应用程序可以快速定位有关他们管理的系统的信息,以便他们能够更高效地响应支持请求。但现在,只有少数人甚至可以登录,当我在隔间之间走动时,看到我经过的每个屏幕上都出现了相同的错误,我感到沮丧,开始在房间里嗡嗡作响。

我们的首席执行官向我挥手致意"嘿,伙计,看来我们有麻烦了" 他一如既往地表现出镇定,但他的微笑是被迫的。尽管他说“我们”,但他的意思是“你”,因为这肯定是我的问题。尽管几个月前才加入这个团队,但当时我是整个八人公司中仅有的两名软件工程师之一,也是当天唯一一名。

那';这就是为什么我发现自己绝望地蜷缩在笔记本电脑前,双手颤抖,在一个对我来说仍然陌生的代码库中搜索,折磨着我的大脑。在过去一周的测试中,这个精确的构建工作得很好。今天有什么不同?为什么不能';没有人登录吗?

每一秒都像是一个永恒的时刻,我试图控制住自己日益加剧的恐慌。“专注,你能做到,”我告诉自己。错误消息是通用的,对缩小问题范围没有帮助,但我知道问题一定与登录功能有关,因为';这是人们陷入困境的地方。

然后它击中了我。今天是我们第一次';d曾经有一大群人同时访问该产品。我还在学习代码库,但我知道我们有一些不成熟的安全功能设置,以防止太多错误的登录尝试。果不其然,当我登录数据库时,我可以看到我们错误地跟踪了登录尝试的总数。它不是计算每个用户的次数,而是计算整个系统中的每次尝试次数。巨大的掌心。

我打电话给团队中的另一位工程师,确认我看到了什么,我要做的不是';t完全疯了,然后启动命令,清除跟踪这些尝试的表。桌子空了。我让埃里克再次尝试登录,我屏住呼吸,听着他键盘的咔嗒声。一秒钟后,我们产品的仪表盘出现在他的屏幕上"我';我加入" 他喊道。

当我听到身后有人说";我也刚进去。它现在起作用了。"

上午剩下的时间里,我在房间里走来走去回答问题,偶尔蹲在一间小隔间后面,小心翼翼地重新擦拭数据库表和额头上的汗水,对这种荒谬的情况对自己咧嘴大笑。尽管我们险些遭遇灾难,但训练最终还是取得了成功。

它';从那天起已经三年半了,感觉时间一眨眼就过去了。

周六的亲自培训课程已经被每月的功能更新网络研讨会、一个松弛的社区、每两周一次的客户入职电话和一个优秀的文档网站所取代,该网站支持全球1500多个MSP和数万用户。该产品最初只是一碗数字意大利面,现在已经转变为一系列经过良好测试的微服务,可以扩展到收集数十TB的配置数据。我们的待办事项过去很短,可以放在白板上。现在,我们的产品管理团队制定了一年的路线图,并每天与用户会面,收集可用性反馈。我们的工程团队已经成长为具有成熟软件开发生命周期的交付机器。

换句话说,如果你今天看到的是团队和公司,你相信我们知道我们一直在做什么是可以原谅的。你';d当然也很难想象早期的事物是多么脆弱和卑微。有时我自己甚至难以客观地记住它,而我当时就在那里!那';这就是为什么我喜欢这个故事。它帮助我更清楚地记得,尽管怀旧的迷雾是玫瑰色的。

他们很艰难,因为一切都很不确定。当我加入时,我们只有五个人:两位创始人、一位销售人员、一位工程师,他在过去六个月左右的时间里一直在构建核心产品的原型,还有我。我们没有';没有任何资金,产品几乎没有功能,我们没有';我们还没有付费客户,我们也没有';我不知道我们需要做什么才能得到他们。

这种不确定性造成了紧张局势。销售人员希望构建更多的数据采集器,创始人希望专注于平台集成,我们工程师希望过度设计用于存储IT配置的图形数据库。我们正以尽可能快的速度工作,并在这之后创造了一个技术债务的坟墓。每个人都很关心,每个人都想让它发挥作用,每个人都很聪明和任性,这意味着我们每个人都会开始朝着我们认为需要的方向努力。我认为这种情况在早期创业公司中经常发生,只有那些在这种情况下幸存下来的创业者有着强烈的愿景,并且能够将这种愿景推销给早期团队。它';这是一个陈词滥调,原因是:如果可以';不要都朝同一个方向划船,你赢了';我没有取得任何进展。

幸运的是,创始人确实对他们想要开发的产品有着强大的愿景。不幸的是,我们不能';我们无法在一夜之间完成这一切,所以感觉工程优先级几乎每天都在变化。我们有很多功能只是实现了一半,很脆弱,或者有缺陷。我们不断地敲打产品的不同部分,慢慢地将其敲定,同时他们积极地与潜在客户会面,并试图完成我们的第一笔交易。我们试图在中间相遇-得到产品到& 34;足够有用";去有人愿意付钱的地方。

我记得当我们达成第一笔交易时,我目瞪口呆,因为我知道当时的产品有多笨重和脆弱。但我意识到,大多数早期的客户并没有购买产品,因为他们购买的是我们试图构建的愿景。我们最早的客户就像是团队的延伸。一滴验证让人上瘾,它让我们持续了更长的时间。因此,我们不断听取客户的意见,并不断对产品进行迭代。产品越来越好,新客户的点滴变成了涓涓细流。

在那些日子里,工程学面临着巨大的压力。没有人确切地知道我们下一步应该啃掉路线图的哪一部分,以及在有人购买它之前它需要有多精致,而且我们有大约2%的带宽来完成队列中的所有任务。

一开始,我常常告诉自己,";一旦我们解决了这个问题,我们';我们就可以稍微少踩油门了" 这是一种谬论。我们目前面临的挑战只是掩盖了它背后无休止的未来挑战。一旦我们得到了第一批客户,我们很快就从单纯的";执行和交付";模式为";继续这样做,但也要修复所有这些该死的错误,否则我们可能会失去这个客户";模式

公平地说,这种压力是自我施加的,而不是有害的工作环境。我们不想让我们的队友失望,这让我们感觉整个世界都在我们的肩上,当产品坏了的时候,我的焦虑症发作的比例超过了我应得的比例。有一次,一位新客户意外地将50000个用户的CSV导入到他的实例中,烧穿了AWS服务限制,并在下午完全挂断了该实例。几个月后,有一段四天的时间,凌晨3点,我被监控警报吵醒,不得不爬下床让应用重新上线,然后一整天都在纠结于寻找根本原因。这些都是具有挑战性但非常宝贵的学习经历。没有什么比一周的睡眠剥夺和压力更能让你感受到观察力的重要性了。

尽管这是一个压力锅,但没有什么比和早期团队一起在战壕里更有趣的了。每个人都在努力工作。这一愿景雄心勃勃,令人兴奋,感觉我们可以看到一个几乎没有其他人能够看到的未来。终于有了一些真正从产品中获得价值的客户,这真是令人振奋。

在我们找到了一些动力并筹集了一些资金后,我们开始发展团队。当时我们雇佣的最初几个人总是来自我们的个人网络。他们要么是我们在合作空间遇到的人,已经和我们商量过了,要么是老朋友或熟人。

一旦我们变得更大,我们就开始在我们的网络之外招聘。这是一个非常困难和耗时的过程(尤其是对于工程招聘),因为我们需要编写工作申请、发布职位广告、熟悉申请人跟踪系统,并使我们的面试循环正式化。我们花了六个月的时间才找到第一份网络工程以外的工作。在那之前,我们有两位候选人进入录用阶段,却发现自己并不是';我对加入我们的团队不是那么认真,一直在通过招聘渠道进行练习,并利用我们的报价作为筹码。这是一次很好的学习经历,但作为一个接受者却让人泄气。不要这样做,尤其是对时间和精力有限的小型初创公司。不管怎样,在我们建立了求职渠道,公司的形象开始增长之后,招聘变得更容易了。一旦我们雇佣了一些可靠的人,我们的集体关系网就扩大了,我们又开始得到推荐。

随着团队的成长,我们所有的内部和外部流程都开始不断发展。团队中有更多的人意味着我们需要更高效的方式让信息在公司内外传播。我们尝试了很多方法:改变团队和部门的组织方式,确保所有会议都有明确的目的,并以正确的节奏安排,确保每个人都知道哪种沟通渠道是为了什么(什么时候放松,什么时候发邮件,什么时候做合流页面),调整我们如何使用任务跟踪工具,以更好地配合我们的合作方式。那里';这是一门艺术,因为改变一个过程会在团队调整时产生心理摩擦,所以你发现你必须平衡改变的必要性和频率,以及你试图解决的沟通瓶颈的严重性。关键是要定期与团队进行反思(回顾是最好的时机),并就小型实验性迭代在团队中建立共识"让';让我们在接下来的两周内尝试一下这个改变,如果它';这不管用,我们';我试试别的"

我们开始慢慢地从团队中的每一位工程师都知道所有的代码,转变为团队中少数拥有这些遗留知识的人,转变为团队中没有人知道所有的代码。正是在这一点上,早期的一些工程决策和代码开始看起来完全疯狂。这是一次超凡的体验,因为这些问题往往是我自己造成的。几年前,在考虑设计折衷方案时,我告诉自己,";如果我们做到这一点,这将是一个很好的问题" 果然,我们终于做到了这一点!

这让我意识到开发过程是多么进化。随着我们的建设,我们正在慢慢完善我们对产品如何为客户带来价值的理解。因此,我们保证会有一些我们不再需要的东西,因为优先级发生了变化,或者我们过度设计了一些东西,因为我们不确定该功能会朝着什么方向发展。我们知道,我们可能应该放弃那些只有0.5%的客户群在使用的东西,或者添加测试并重构那些';我们很难与之合作,但我们的产品团队希望我们专注于实现路线图承诺。没有足够的带宽在两个方向都能完美执行,所以你必须找到一个折衷方案。不要因此而沮丧!记住:每个人都在向他们认为对公司有利的方向努力。产品团队(以及工程部门以外的所有部门)最终想要的都是你想要的东西——快乐的客户和成功的结果——因此,让他们意识到他们看不到的地雷,同时仔细倾听,确保你没有忽视大局,这一点很重要。它';当人们感到被倾听时,建立共识就容易多了。

在某个时刻,我抬起头,意识到我现在在一家“真正的公司”。我们筹集了多轮资金,团队中有100多人,我们有数千名客户。我每周与其他部门负责人举行一次管理层会议,向他们介绍团队KPI的最新情况,每月与首席财务官和我们的工程副总裁举行一次会议,审查预算和招聘计划。我不再有那么多的空间去思考代码和架构,因为我做了很多一对一的工作,面试候选人,与产品管理团队会面,讨论改变路线图优先级。换言之,在一台运转良好的机器上,我变成了一个小得多的齿轮,就像公司里其他人一样,此时此刻,我不再是任务关键型的。

这是一种苦乐参半的感觉。一方面,这很美妙,因为这意味着我们已经成功地构建了一个能够独立存在的流程和产品,这一直是我们的目标。另一方面,我感到一种失落感。我连续10个小时错过了黑客攻击的日子,那时积压的文件放在白板上,整个团队可以围坐在一张桌子上。我没有亲自认识公司里的每一个人,也没有认出使用我们产品的每一家公司的名字。我甚至错过了早期的一切是多么破碎和混乱,当时一阵风似乎会导致正常运行时间警报响起,或者你需要截断一个行为不当的数据库表,以防止亲自培训课程演变成灾难。

在我职业生涯的早期,我只想成为一家高增长初创公司的一员。我曾经认为,为了取得成功,一家初创公司必须正确地做出绝大多数战略决策,就好像建立一家伟大的公司就像踮着脚尖走过一条钢索。

现在我已经成为了其中的一员,我相信这与其说是让每件事都正确,不如说是专注于你能控制的:耐心和坚持。旅程很长,一路上你会遇到很多麻烦。这是一个没完没了的循环,每天都出现,犯错误,认识到错误,然后把你学到的东西应用到第二天做得更好。如果你想最大化你的成功机会,找创始人(或者成为创始人!)他们有谦逊和坚韧的精神,致力于这个不断进步的循环。然后,每天都面带微笑,准备好磨磨蹭蹭。几年后,当你回首往事时,你会惊讶地发现自己已经走了这么远。

如果你正在为你的团队寻找软件工程经理或高级软件工程师,我';我正在慢慢地从我现在的角色过渡过来,很想聊天!