4 ms·
It’s amazing the overhead the “traditional” or “agency” model brings with software development and how it reduces engineers to developers who just need to execu
by gregdoesit 6y ago
It’s amazing the overhead the “traditional” or “agency” model brings with software development and how it reduces engineers to developers who just need to execute whatever it’s decided by people up the chain. No wonder autonomy, leverage, career progression and pay are all more limited in this setting. I wrote in more detail about exactly this “backwards” approach and its implications [1]
Compare this with how some of the fat-moving companies work. Instead of 7 different people (from BA and PM and a dedicated DevOps engineer etc etc and all the comms overhead) you have two people / roles:
- Product & design: the “why” and “what”
- Software engineers: the “how” and building/shipping. Note that these people are called engineers for good reason at these companies. While the article says “ A team full of great developers may not bring the expected outcomes if there’s poor communication.” - duh, at places I’m talking about, engineers communicate with each other without a project manager for the most part. In fact, decent comms is something these companies screen for during the interview process. And “DevOps” is part of the role: you build it, you own it. Of course, there would be platform-focused teams and program/feature teams.
These tech companies have other roles for sure: most notably, data scientists and other not-so-technical roles (marketing, operations, legal etc)
But by having one engineer own what companies like SteelKiwi have several people do, no wonder they’ll be able to move faster (less comms overhead), pay more (far more value per engineer) and provide more autonomy (you own solving the problem, not executing the task the BA and PM agreed on, and you’re not expected to understand anyway).
[1] https://blog.pragmaticengineer.com/what-silicon-valley-gets-right-on-software-engineers/ https://blog.pragmaticengineer.com/what-silicon-valley-gets-...
- lobsang 6y agoThis, although I would call it the 'enterprise' model. This is how teams in the UK Gov are structured (infact we have more roles [52 at last count]) and its horrible. Aside from the lack of ownership and autonomy at an individual level you also end up with increadibly fragile teams as theres no depth of experience. If you have 7 people and they all do different things you spend more time finding things for people to do than working on valuable problems - much better to find people with overlapping skillsets in the domain you want to solve a problem then let them get on with it. So if you want to build some software - hire people that can write code, if you want to provide information - hire some writers. Hire smart people and they can do the bits around the edges 'enterprises' think they need specialsists for. "A jack of all trades is master of none, but often times better than a master of one"
- Quarrelsome 6y agooh wow, this is everything I've ever wanted. I guess I need to go work for an SV-like company.
- jameshart 6y agoThe challenge agencies have to deal with, that internal dev teams don't, is that with a contract software engagement, every conversation between the developers and the customers risks impacting the contract terms. In an internal software project, when an engineer looks at a problem and realizes it can be trivially solved with an off-the-shelf airtable template, that's a win for everyone! Less code to maintain, less distractions from other more valuable projects, and value delivered sooner. If a developer working for an agency realizes that, and says it out loud during a meeting with the client, they just undermined the basis for the entire engagement.
- camgunz 6y agoAn agency that bilks their clients this way should face consequences. Engineers spilling the beans is a weird oversight system but, whatever works I guess.
- 908B64B197 6y ago> It's amazing the overhead the "traditional" or "agency" model brings with software development and how it reduces engineers to developers who just need to execute whatever is decided by people up the chain. It's a good approach if you can't attract great talent to begin with. You'll pay lower and have a higher head count so costs are about the same. SV has the talent pool and the compensation to make it attractive to work there.