Measuring a company by its “agility”, or how cutting-edge and progressive its tech stack and development processes are, can be an excellent method upon which to compare companies.
In this article I will be comparing three real companies, known unimaginatively as “Company A”, “Company B” and “Company C”. I’ve found it fascinating to learn about each of these companies and their leaders- particularly that they all manage to be very successful, growing companies despite each having their own ways of doing things. I worked at one and interviewed with the other two, but I always ask a lot of questions during these interviews and walk away knowing a lot about how each does things.
在本文中，我将比较三个真实的公司，它们被想象为“公司A”，“公司B”和“公司C”。 我发现了解这些公司及其领导者非常有趣，特别是尽管他们各自都有自己的做事方式，但他们都设法成为非常成功的成长型公司。 我曾在其中一个工作过，并与其他两个人进行过面谈，但是在这些面试中，我总是会问很多问题，然后走开，对每个人的工作方式都了解很多。
Each of these companies has a lax culture, competitive benefits, and at least some truly-senior developers. All leaders worked their way up from software development positions, and two of the three (B and C) still write code as part of their daily job responsibilities.
公司A —“成熟的创业公司” (Company A — The “mature startup”)
Company A is fast-paced, innovative, cutting-edge… dare I say, agile. Indeed, they follow Agile (or at least try to) as closely as they can, including daily stand-up meetings, sprint planning meetings, two-week sprint cycles, etc. They use the latest technologies- React (with hooks!), .NET Core, and some emerging technologies like GraphQL, RabbitMQ, and MemSQL. They have a dedicated DevOps team and an automated deployment pipeline.
公司A节奏快，创新，尖端……我敢说， 敏捷 。 确实，他们尽可能地遵循敏捷(或至少尝试着)，包括每日站立会议，冲刺计划会议，两周的冲刺周期等。他们使用最新技术-React(带钩子)， .NET Core和一些新兴技术，例如GraphQL，RabbitMQ和MemSQL。 他们有一个专门的DevOps团队和一个自动部署管道。
Company A is a seasoned startup that has been bought out but not completely reorganized by its new owners. Pre-buyout management has remained, and culture has “remained the same” (although it never actually does, as it turns out- benefits are always cut for example).
基于知觉的好处 (Perception-Based Benefits)
Company A hires the best talent in town with a famous culture and the ability to work in a cutting-edge stack. They pay below market, but their devs value the culture over $10 or $20k. This culture is what I refer to as “perception based”. This means that the culture benefits are “off the record” and hidden from the parent company (if applicable) and sometimes even HR, and apply on a person-by-person basis based in part on who their manager is and which team they are on, as well as perception of the individual by others. These benefits include consistently working < 40 hours per week, taking well beyond one hour for lunch, playing video games on company time, and not submitting PTO requests when out sick. Some employees were fortunate enough to enjoy all of these benefits, while others wouldn’t be able to get away with any. These were largely benefits established in the early days of the company, passed on to new employees by the employees who have stuck around since those early days.
公司A聘请镇上最优秀的人才，他们拥有著名的文化和能够在最前沿工作的能力。 他们的付出低于市场，但他们的开发者对这种文化的评价超过10美元或2万美元。 我所说的这种文化是“基于感知的”。 这意味着文化收益是“记录在案的”，对母公司(如果适用)甚至是人力资源都是隐蔽的，并且是逐人申请的，部分取决于其经理是谁以及他们是哪个团队以及他人对个人的感知。 这些好处包括每周持续工作少于40小时，午餐时间远远超过一小时，在公司时间玩视频游戏以及在生病时不提交PTO请求。 一些员工很幸运地享受了所有这些好处，而另一些则无法摆脱。 这些主要是在公司成立之初就建立的福利，并由那些自成立之初就一直留在公司里的员工转移给新员工。
Officially the workweek is 40 hours, but varies widely from employee to employee, with some working an average of 35 hours per week and others putting in closer to 45 hours per week.
不惜一切代价敏捷 (Agile at All Costs)
Company A is what I would describe as “Agile at All Costs”. That is, the company’s adoption of Agile has negative impacts on the company’s culture, employee productivity, ability to deliver new features that are bug-free, etc. (I will expound on this in a forthcoming article, but “Agile” implemented poorly or incorrectly can have disastrous consequences).
我将公司A描述为“不惜一切代价敏捷” 。 也就是说， 公司采用敏捷对公司的文化，员工生产力，提供无缺陷的新功能的能力等产生了负面影响 。(我将在即将发表的文章中对此进行详细说明，但是“敏捷”的实施效果不佳或错误地会带来灾难性的后果)。
领导者A-从开发者晋升为导演 (Leader A — Promoted from dev to director)
When hiring, Leader A tends to look for devs “passionate about code” (same as the other two leaders of the other two companies).
Leader A is typically very open to change and will allow dev teams to try new things, even when it may not make total sense and is really just “for the experience” or “just to try it out”.
团队架构 (Team Structure)
There is a strong adherence to the company’s interpretation of Agile. Teams are usually small (3–5 developers) and each team typically has a “lead”, the most-senior developer. That said, this lead is not formally recognized as the lead, and does not actively “lead” the other developers on the team. Equality in responsibility and leadership is promoted among a team’s developers, QA and product manager although in practice the product manager is taskmaster and effectively assumes the role of “manager” for the team- managing the assignment of work items, organizing and leading meetings, and serving as the liaison to the stakeholders.
该公司对敏捷的诠释有很强的依从性。 团队通常很小(3-5个开发人员)，每个团队通常都有一个“领导”，即最高级的开发人员。 就是说，这个潜在客户没有被正式认可为潜在客户，也没有积极地“领导”团队中的其他开发人员。 在团队的开发人员，质量保证和产品经理中，责任与领导力的平等得到了促进，尽管实际上产品经理是任务负责人，并有效地承担了团队的“经理”角色，管理工作项目的分配，组织和领导会议，以及担任与利益相关者的联络。
Team members are often shuffled around to other teams, sometimes as often as once every few months. In this way, knowledge is more spread-out among the developers, and developers are able to more or less choose which application or product they want to work on (as a result, they have some control over whether they work primarily on backend or frontend code).
The average developer competency is as high or higher than any other company (good habits are reinforced and advanced knowledge is passed down to the less-experienced developers)
“Perception-based” benefits can be extremely generous.
It is difficult for mid-level developers to be promoted to senior-level.
An ever-degrading culture (which will always degrade as a company grows, especially if the company is acquired by another company).
Working some amount during nights and weekends is somewhat common to meet deadlines or fix unexpected production bugs.
Company A is a “mature startup”- a company that is still relatively small, has a few employees who were there from the early days, may be in the transition phase from startup to enterprise- isn’t sure whether it’s a startup or a large company.
Company A is great for college-grads and junior developers to learn from some of the smartest developers in town (and in fact junior devs who go through the internship program are paid above market at Company A as a means of incentive).
Mid-level developers are expected to work very hard on mostly feature enhancements for brownfield applications. For mids, there is plenty of learning and growth opportunity, but they are paid significantly less than their peers at other companies (where they would generally be considered “senior level”). Many mid-level developers at this company are qualified to be promoted to senior, but there is only so much room at the senior level and so the “best of the best” must be chosen. The criteria to be considered “senior” is intentionally hidden, likely because the lucky few who are promoted are chosen less by their development and leadership skills and more how well-liked they are by leadership (whether you believe this or not, watch out for it at your job).
预计中级开发人员将在棕地应用程序的大部分功能增强上进行艰苦的工作。 在中期，有很多学习和成长的机会，但是他们的薪水比其他公司的同行要低得多(在其他公司，他们通常被称为“高级”)。 该公司的许多中级开发人员都有资格晋升为高级职位，但是高级职位只有这么多的空间，因此必须选择“最好的”。 被认为是“高级”的标准是有意隐瞒的，这可能是因为晋升的幸运儿很少通过他们的发展和领导技能来选择，而更多地是通过他们对领导的喜欢程度来选择(无论您是否相信，请当心它在您的工作中)。
A mid-level developer at this company would be wise to take a couple of years of experience and growth and use it to land a senior role at another company, unless they are on the shortlist for a promotion (and the criteria for a “senior” is known, and that mid-level developer meets that criteria).
Senior developers enjoy a lax work environment while having the ability to work on mostly greenfield development using new and unfamiliar technologies that interest them.
C公司-旧血液 (Company C — The Old Blood)
Company C values and strives for that magical (if not unrealistic) blend of “speed” and “quality” same as Company A, yet somehow seems to work at a slower pace. At least, the sense of urgency is absent from the office atmosphere. Company C is slow to change and far from cutting-edge, opting to use older technologies like jQ**** and WebF****, and use stored procedures to store business logic (gasp!). I remember when I was interviewing at this company I was amazed at how, despite the long list of so-called “best practices” being broken and ignored, the company was doing well- so well in fact, that they were on a sort of hiring spree.
公司C重视并努力与公司A进行“速度”和“质量”的神奇(即使不是不切实际的)融合，但在某种程度上似乎工作速度较慢。 至少在办公室气氛中没有紧迫感。 公司C的变化缓慢，并且远离尖端技术，选择使用jQ ****和WebF ****等较旧的技术，并使用存储过程来存储业务逻辑(天哪！)。 我记得当我在这家公司面试时，我惊奇地发现，尽管一长串所谓的“最佳实践”被打破并被忽视了，但该公司的表现却很好，事实上，他们在某种程度上招聘狂潮。
There’s a certain allure about being “stuck in time”- knowing everything you will ever need to know to do your job and do it well. There is no “keeping up” with jQuery. We’re taught as developers we need to be so passionate that we want to learn about all the new things constantly being released, but I don’t see an issue or a lack of passion with someone who is content writing jQuery for the rest of their career
“被时间卡住”有一定的吸引力-知道完成工作和做好工作所需的一切。 jQuery没有“跟上”。 作为开发人员，我们被教导要充满激情，以至于我们想了解不断发布的所有新事物，但是对于那些为其余的内容编写jQuery的人来说，我没有看到问题或缺乏热情他们的职业
领导人C-创始人兼首席执行官 (Leader C — Founder and CEO)
Leader C, from their perspective, has created a system that works well, and continues to milk it. That system- using an outdated tech stack, ignoring certain best-practices, and refusing to acknowledge Agile as something of any value whatsoever- made them their first profit and continues to do so to this day. Leader C is stubborn against any change to this formula.
从他们的角度来看，领导者C创建了一个运行良好的系统，并将继续发挥作用。 该系统使用了过时的技术堆栈，忽略了某些最佳实践，并且拒绝承认敏捷具有任何价值，这使他们获得了第一笔利润，并且一直持续到今天。 领导者C坚决反对对此公式进行任何更改。
“culture fit” matters less (likely influenced by the median age of development staff being as high or higher than any other company around).
Likely low-stress work environment (burnout may be caused by “lack of subject knowledge” rather than “working too much” — I have found this to be true — ergo a dev job where you already know most everything you will ever need to know, should be low-stress).
可能是低压力的工作环境 ( 工作倦怠可能是由于“缺乏学科知识”而不是“工作过多”所致-我发现这是对的)-进行开发工作，您已经知道了几乎所有需要知道的一切，应该是低压力的)。
New, better ways of doing things are often ignored in favor of established convention that is “known to work” (e.g. business logic in stored procedures, no modern patterns such as MVC, Repository Pattern, etc.).
Development staff stops learning and growing and essentially repeats their x year of development for as long as they are there (as the saying goes, mid-level devs can repeat their Xth year of experience over and over and never make the leap to “senior” despite having perhaps 10 years of experience).
Company C has been around for a long time and is startup-sized (although often such a company is a very large, stereotypically-corporate entity).
For junior developers, Company C can be a great way to get your feet wet. Often Company C-type companies will have a stack most-similar to what junior devs learned and worked with in college.
For mids and seniors, working at Company C means forgoing experience that is needed for career advancement, in exchange for being allowed (perhaps even encouraged) to stagnate from a knowledge and skillset-expansion standpoint.
公司B-两全其美？ (Company B — The Best of Both Worlds?)
Company B is last in this list because Company B is a blend of Companies A and C in almost every way. Company B, unlike Companies A and C, are mercenaries of sorts. Their business model is comprised of creating custom applications on contracts for their clients. They don’t have a product, per sé. They are the product (or rather, the service). As far as the tech stack is concerned, they are solidly between A and C- not cutting edge, but still keeping up with current trends, more or less. As a contractor, Company B chooses their stack based on the client they are building for. For example, if the client intends on managing the application after Company B delivers it, Company B will use a stack their client’s developers are familiar with. Sometimes this means using jQuery in lieu of React/Angular/Vue.
公司B在此列表中排在最后，因为公司B在几乎所有方面都是公司A和C的混合体。 与公司A和C不同，公司B是各种雇佣兵。 他们的业务模型包括为其客户在合同上创建自定义应用程序。 暂时没有产品。 它们是产品(或更确切地说，是服务)。 就技术堆栈而言，它们稳固地处于A和C之间-并非最前沿，但仍或多或少地跟上当前趋势。 作为承包商，公司B根据要为其建造的客户选择堆栈。 例如，如果客户打算在公司B交付应用程序后对其进行管理，则公司B将使用其客户开发人员熟悉的堆栈。 有时，这意味着使用jQuery代替React / Angular / Vue。
Company B is “Agile”, but effort has been made to customize Agile to best benefit the company.
Culture fit is important, but not in the conventional sense. Leader B hires developers who view software development through a certain lens that includes “passion” not being defined by eagerness to learn the very latest languages, libraries and frameworks.u
领导者B —创始人 (Leader B — Founder)
Leader B believes very strongly that the workweek maxes out at 40 hours, and actually enforces this. Employees are strongly discouraged from working more than 40 hours in a week, and if they go over 40 hours, they are subject to “frowning upon” similar to if you or I put in only 35 hours at our jobs. From their perspective, needing to work more than 40 hours per week suggests inadequate ability on the part of the employee working more than 40 hours.
领导者B非常坚信，每周的工作时间会在40小时后用尽，因此实际上是强制执行的。 强烈建议员工每周不超过40个小时的工作，如果超过40个小时，他们将遭受“皱眉”，就像您或我只工作35个小时一样。 从他们的角度来看，每周需要工作40个小时以上，这表明员工工作40个小时以上的能力不足。
Leader B is pragmatic and will not change procedure simply because another company does x when Company B is doing y. Leader B is open to change, but it must be practical and for good reason. In other words, Leader B falls in between Leaders A and C when it comes to “stubbornness”.
领导者B 务实 ，不会仅仅因为另一家公司在公司B做y时做x而改变程序。 领导者B愿意改变，但必须切实可行并且有充分的理由。 换句话说，当谈到“固执”时，领导者B介于领导者A和C之间。
团队架构 (Team Structure)
Teams are small, consisting of only about three devs. Teams are almost always set in stone, meaning when you join the company, the team you are placed on is likely the last team you are ever placed on at Company B.
Each team has a lead developer; lead developers at Company B spend about half their time writing code and half their time doing “leader things” like code reviews, architecting new projects and even meeting with the company’s paying clients for design, deployment and troubleshooting of the application the team builds. Leads can also use their “50%” time to read books and articles, and watch instructional videos to further develop their software development and management skills.
每个团队都有一名首席开发人员； B公司的主要开发人员花费大约一半的时间编写代码，一半的时间用于执行“领导力”，例如代码审查，架构新项目，甚至与公司的付费客户进行团队构建的应用程序的设计，部署和故障排除。 潜在客户还可以利用其“ 50％”的时间阅读书籍和文章，并观看教学视频，以进一步发展其软件开发和管理技能。
“Agility” is balanced and driven by what is best for a particular project for a particular client (this means that harmful Agile practices are abandoned and time requirements to keep up with latest tech developments are reduced).
Strict enforcement of 40-hour workweek (many companies say there is good work-life balance and will never straight-up ask their employees to work nights or weekends unless absolutely necessary, but these same companies won’t stop you, either).
Incentives for continuing education (100% tuition reimbursement, bonuses for obtaining certifications)
- None 没有
Company B appears to take the best from Company A and Company C to create “the perfect dev shop” to work for. Company B emphasizes management and leadership skills in their lead developers.
As far as I can tell, Company B is a great place for junior, mids and seniors; juniors and mids, to grow their software development skills, and seniors to grow their management and leadership skills.
The purpose of this article is to compare three very different companies, each in different positions on a spectrum of “Agility”, or how cutting-edge they are with respect to tech stack and SDLC practices. I can think of multiple companies here in my city that are virtually exact matches to Company A, Company B, and Company C. That can’t be a coincidence, and I am hoping others can use the “templates” of these three companies to compare against companies they currently work for or are interested in working for, to be aware of potential “tragedies” and ultimately to aid in the decision of which company to move to.
Is Company B the “best” of the three because of its semi-Agility? Or is its semi-Agility merely an indicator that the company is well-led? Is semi-Agility (partial adoption of “Agile” and the “latest” technologies) a good thing?
就是因为它的半敏捷的B公司的三个“最佳”？ 还是它的半敏捷性只是该公司经营良好的指标？ 半敏捷(部分采用“敏捷”和“最新”技术)是件好事吗？
Regardless of which of the three companies you consider to be the best, you should try to have answers to all of these questions before accepting a job offer:
How interested is your direct report in promoting people? In promoting you? I’ve had managers express 0 interest in my professional development, and I’ve had managers explain and show me exactly what I need to do in order to get promoted- totally unsolicited (because it’s their job to move underlings up the ranks)! I suggest asking your would-be manager this question directly, even if that means arranging to meet with them yourself outside of the formal interview process (a quick phone call).
您的直接报告对促进人的兴趣如何？ 在提升你？ 我已经让经理对我的职业发展表达了0的兴趣，并且我已经经理进行了解释并向我确切展示了如何获得晋升-完全是不请自来的(因为将下层员工升职是他们的工作)！ 我建议直接向您的潜在经理询问这个问题，即使那意味着要在正式面试流程(快速电话)之外亲自与他们会面。
Is there clear and explicit criteria the company uses to define the various levels of software developer titles? You don’t need to know what that criteria is, just that it exists in a concrete form (written down somewhere) and not in someone’s head.
Are they placing you where you feel you should be? Not every company considers me a “senior level” developer, but many do. Why would I work for the ones who don’t? This is about self-esteem as much as it is about resume-building.
他们会将您放置在您应有的位置吗？ 并非每家公司都认为我是“高级”开发人员，但很多公司都认为我。 我为什么要为那些没有的人工作？ 这与建立自尊心一样重要。
Are career-advancing activities on your part encouraged or rewarded by the company? Things like tuition reimbursement, bonuses for passing certifications, and paying for employees to attend conferences.
Is the tech stack something you are comfortable with? Will you be able to transfer the experience gained with this stack to your next job? If you take a job at the only Ruby shop in town, don’t be surprised if you have to move in order to find another Ruby gig when the time comes to change employers.
您对技术堆栈感到满意吗？ 您能否将通过此堆栈获得的经验转移到下一份工作？ 如果您在镇上唯一的Ruby商店工作，当需要更换雇主时，如果必须搬家去寻找另一个Ruby演出，不要感到惊讶。
How often do employees have to work nights and weekends? The notion that this is a “startup problem” is untrue. For example, I’ve worked at a “Company C” that expected at least 45 hours per week as a minimum. I find it is best to ask former employees (who left within the last year) rather than current employees to get an honest answer to this question.
员工多久必须晚上和周末工作一次？ 这是“启动问题”的说法是不正确的。 例如，我曾在“ C公司”工作，该公司预计至少每周至少45个小时。 我发现最好问过去的雇员(在去年内离职)，而不是现任的雇员，以得到这个问题的诚实答案。