![]() Passing context down and giving autonomy to make decisions is how efficient organizations pull ahead. Leaders know that it's in the best interest of the business to share all relevant business context with them, and give space for execution. Some traditional companies still work like this.Ĭompare this with places where engineers are recognized to have the ability to solve problems on the ground better than anyone else. Need I add that this bank was struggling with how their software department was (not) working? A hierarchical view of the world. ![]() Basically, those doing the work did not have a say - by design. Decisions were allowed to be done from level three. I've talked with people at a bank that had six levels of project management. It impacts the day-to-day life of any engineer.Īt traditional companies, the notion of devs do what they are told often ends up with a hierarchical setup. At SV-like companies, it's to solve problems that the business has. The expectation from developers at traditional companies is to complete assigned work. And it is uncommon for managers to tell engineers what exactly to do, to break down their work into small chunks or to micromanage them. It's common to see services and features built that engineers suggested or have teams spend dedicated time paying off tech debt that people on the team advocated for. Regardless of how it's done, all engineers are incentivized to look at the big picture, to unblock themselves, and to solve any problem they see.Įngineers taking initiative is something "SV-like" companies celebrate. At other places, engineering managers or senior engineers could do this work. In some places, each project would have an engineer leading it, who facilitates breaking up the work. But for the most part, engineers are expected (and encouraged!) to figure out the "how" of the work, including making larger decisions. There are projects, and there are program managers and engineering managers. Join a "SV-like" company, and you'll see little of this. There's little need for questions unless it's about clarifying a detail in the ticket. These tickets are vetted by the product - or project - manager, and they have most key details to do the work. In "traditional" companies, developers get work items assigned to them - most often JIRA tickets. Here are the key things these companies "get" better than many others. ![]() They use similar methodologies and can often attract talent from other "Silicon Valley-like" companies. They are the kind of companies that are comparable in working output per engineer to the likes of Facebook or Google. In this article, I'll use the term "Silicon Valley-like company" to refer to modern companies who create high leverage with each software engineering hire, and who have traditionally been headquartered in Silicon Valley - though many newer ones no longer got started there. In turn, Silicon Valley companies can (and do!) pay higher wages, and they get more value out of the same person. These are practices that result in faster innovation at a company-level, better professional growth for engineers, and just better "utilization", for the better word for it. I've noticed that Silicon Valley companies consistently "get" a few things that their traditional counterparts fail to either understand or implement in practice - especially in Europe. This mix had a healthy sample of Silicon-Valley companies and ones headquartered outside this region. I've also talked with software engineers working at startups, banking, automotive, big tech, and more "traditional" companies. I've worked at various tech companies: from "traditional" shops and consultancies, through an investment bank, to high-growth tech firms. ![]() Menu What Silicon Valley "Gets" about Software Engineers that Traditional Companies Do Not
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |