We don’t post salary ranges right now. We are a small firm and cannot keep up with the salaries from enterprises in our area. We are looking for (and finding) candidates that are willing to sacrifice parts of their salary for 100% remote, flexible work time, PTO and others.
We decided to screen applicants in an informal phone call and discuss salary options at the end, after they had a first impression of how we are as a firm.
You think you're hot shit on a silver platter. You apply for jobs with high TC listed and others which you believe will also be high TC based on... reasons, even though they don't list their salary ranges.
You get callbacks from some of the high TC positions you applied for. You also get callbacks from the non-listed salary positions. Cool. None of the highest, none of your first choices, but whatever, an interview is an interview.
You go through the processed and find out a lot of the non-listed positions have TCs much lower than you were hoping for. TCs so low, you wouldn't have considered the job if you had known. Whatever, you'll just ghost them. What's good for the goose is good for the gander.
But then the days stretch on and the only positions submitting offers are the low TC jobs you applied for. You take the blow to your ego along with the job. Gotta pay those bills.
but in that case... isn't it bad for the employer if the person is not actually happy with the salary is they are going to bail as soon as they find something else?
That's assuming they can. In my hypothetical scenario, it's their best offer because it's actually where they should be but our hypothetical protagonist has an over-inflated sense of self-worth.
Like I said, it's just a possible scenario where I can see how not posting their range could get them more applicants.
You should! Not everyone wants to work as a cog in the giant enterprise machine. I've taken a lower salary from a small company specifically because they are small.
I would caution you against the "willing to sacrifice parts of their salary for 100% remote, flexible work time, PTO and others." mindset though. 100% remote, flexible work time, PTO, and other benefits are not added bonuses at this point: they are the minimum requirements for many positions/prospective employees. Instead, focus on the selling the qualities of your workplace that make people happy to work there (for instance, work/life balance, no red tape/micromanagement, creative freedom on solutions, interesting problems to solve, etc).
Why do you want to mislead these people in the first place? The advert has a role in filtering, and in turning down many people you are avoiding wasting time both for you and the potential candidate.
IMO, things like the ability to work remotely, set up a flexible schedule and get a nice amount of paid time off are part of the compensation as much as the salary.
Some people just want money; hoard it like a dragon, invest, retire early. Others are perfectly fine with earning less if they can live better lives in exchange. After all, what's a huge pay check worth if you can't enjoy your hard-earned money in the prime of your life? Or perhaps the dev has a family and prefers spending time with their kids? You can still make money later in life, but your kids' life milestones are irreplaceable.
Posting a lower salary position may attract different people (i.e. people who value their private life more than the money) but that's not necessarily a bad thing. With enough experience, someone can always get more money elsewhere; their employment may only last until the second a better job offer comes in. People who value the additional benefits more are less likely to get them at other companies, as the market is aimed at making the most money right now, so I'd expect them to stick around longer and have more of a vested interest in the success of your company.
You may miss out on top players who want to see their money's worth, but if your package is as good as you say it is, I don't see why you wouldn't post your salary ranges. Focus the ad on what makes the job great and add the range for transparency and I'm sure you'll find the right people.
How has that gone for your firm? Why was the decision made not just be upfront about the salary? If you are afraid that people won't be willing to work with you if they knew the salary then why potentially waste their time?
The first impression of how you are as a firm is the job ad, and if you don't post a salary the first impression is worse.
Whenever I come across teams with situations outlined as in this article and I talk to the people involved, it becomes apparent that Scrum was implemented for the sake of implementing Scrum without understanding. The values and the concept of empiricism are important to grasp in order to effectively leverage Scrum - that is why you have a Scrum Master, not as a manager of any kind, but as a coach and facilitator.
The main challenge I see people having is that Scrum was designed in a way that it screams in your face when you screw up and many organizations fight that instead of inspecting and adapting their way of working.
Despite him not saying "Scrum", the structure he's describing is not Scrum anyway. It might be close to what some people understand when they say "Scrum", but it is not Scrum.
It establishes a set of steps that need to be followed (often time daily) and interactions to be had regardless of the nature of the work and the psychology of evolving unique set of relationships inside a social group? How does it not?
Aren’t these interactions put in place to create transparency across the team regarding progress and purpose as well as empirical validation? I am not sure how that necessarily clashes with social structures inside the Scrum Team or micro manages its members.
> I am not sure how that necessarily clashes with social structures inside the Scrum Team or micro manages its members.
I would expect emergent behavior from said team (which I consider a team; not a SCRUM team; a human team working on software) to be a better representation of who they are as humans and of how they best think they should organize in order to attain the company goals.
As for the micromanagement, I would love to hear an explanation of how SCRUM is *not* micromanagement when every day, a guy (which in my decade long experience has always been either a manager-role or someone wanting to be a manager) comes and gets the report on the tasks that you work to the granularity of one hour (sometimes even 30 minutes for properly crazy SCRUM masters) and intervenes afterwards if he considers it needed.
> Aren’t these interactions put in place to create transparency across the team regarding progress and purpose as well as empirical validation?
Depends on how big you think the team is... If we're talking about a small cross-functional team, I've never had as much transparency and signal over noise over progress, purpose as well as empirical validation, than I had working with a bunch of great people (healthy mix of junior, middle and senior), going out eating every day for lunch (usually more than one hour :o) and discussing.
If we're talking about the organization as a team, then yeah, clearly more transparency regarding progress for them because before this whole SCRUM thing they didn't have a load & run way of creating an analytics pipeline for their software projects.
Look, you're clearly in the SCRUM side of the stadium and I'm squarely in the emergent-process side, and it's been a discussion for aeons of which I am tired. What I am arguing is not pro / anti SCRUM, what I am arguing is that SCRUM as most enforced things "micromanage and/or ignore human psychology".
> what I am arguing is that SCRUM as most enforced things "micromanage and/or ignore human psychology".
I think you are arguing Scrum can lead to these situations - which you cover in your other thoughts. And I agree, I have seen that often, however, I’d still don’t say it’s inherent to Scrum itself.
> how SCRUM is not micromanagement when every day, a guy (which in my decade long experience has always been either a manager-role or someone wanting to be a manager) comes and gets the report on the tasks that you work to the granularity of one hour (sometimes even 30 minutes for properly crazy SCRUM masters) and intervenes afterwards if he considers it needed.
Yeah that’s awful micro management. I know it’s easy to dismiss that way, but what you are describing is not Scrum, that’s just saying Scrum and making people miserable.
In the end, I do not want to argue for Scrum as the solution for everything. It’s really hard to do it right. On one of the teams I am consulting right now, we went away from Scrum because it didn’t work - fascinatingly due to different reasons as you mention, different mindset in terms of what management does and how control is exercised.
> I know it’s easy to dismiss that way, but what you are describing is not SCRUM
I think it's easy to dismiss because this was easy to digest in the first years and first teams, but after a decade and corporations and some smaller companies and some startups, I just don't believe it anymore.
I am actually a certified SCRUM-master (but not practicing) and sometimes google 'what is SCRUM?' just to check up on the new articles. I find a million of them each with their own interpretation that could just work and each of them seemingly valid while mostly ignoring the agile manifesto they love so much.
> On one of the teams I am consulting right now, we went away from Scrum because it didn’t work
Congratulations on actually attempting to solve the problem and not cargo-culting a magic solution.
Status updates every hour or half hour sound like a productivity hellscape. How do people get anything done with such invasive interruptions throughout their working day? You can't even enter a flow state with those sorts of requirements.
> Status updates every hour or half hour sound like a productivity hellscape
(SCRUM-master / AGILE coach / Project Manager / Line Manager) felt like she was losing control of the development and doubled down on processes to the point where nothing moved anymore and this was her solution to it. It was amazing!
One software solution (nothing fancy, just a shit payment processor integrator), three teams, three technical leads, three team leads and one incompetent master overseeing the Kafkaesque nightmare.
Now you're making me curious if the project is still ongoing. :P
> How do people get anything done with such invasive interruptions throughout their working day?
They mostly didn't really, the biggest concern in that company was how to tweak your timesheets to match the estimations as requested by the master.
----
A lot of times when I'm hating on SCRUM I wonder if I really got unlucky, especially due to my outsourcing beginnings, but then I find it hard to understand how come I get lucky to work with great teams when there are no such barriers in place.
I'm not even against the whole process thing, used to build emergency management systems where we spent 80% of the time planning, estimating, figuring out what can go wrong, working in heavy processes. But they made sense.
> Aren’t these interactions put in place to create transparency across the team regarding progress and purpose as well as empirical validation?
Original motivation does not changes anything, we are talking about effect here. Effect is the same.
Also, transparency regarding progress and purpose does not require scrum. I dont know what you mean by "empirical validation".
I don't recall the "not knowing the progress" being issue in any methodology for developers. Maybe, most of the time we dont really need to know how fast tasks are progressing. Speed on other tasks is important for management, but not for me. I need to know their thoughts about codebase, about where to go, what they consider issues and such. But progress, not so much.
Transparency is provided by a Jira board - and the board is always up to date. Purpose and blockers are better discussed 1:1 or in small groups with whoever is in charge of dealing with the stakeholders.
Micromanagement - there is literally ability to make own decisions. You have to accountability either. Every single tiny aspect of work is dictated by somebody else, commitee or some kind of process.
Personal guess: groups full of people with high interest in people and great social skills won't produce something like scrum. It exists only because tech can give decision power to people who don't have those.
Human psychology: to large extend the above. It leads to absurd conflicts and power struggles over nonsense. Then it blames people who actually reacted in predictable way. It creates unnecessary hard social situations.
It is also massively demotivating. In fact, the components of motivations in pretty much any other fields are autonomy, mastery, accountability. Scrum lacks all three.
> Every single tiny aspect of work is dictated by somebody else, commitee or some kind of process.
That is not the way Scrum is meant to be implemented. The goal is to have a cross-functional, empowered team with the ability to make their own decision. The Product Owner - as part of that team - makes ultimate decisions as to what the product will be.
> It creates unnecessary hard social situations
Yes, social conflicts in team can be tough. Following the values of Scrum, respect and openness in particular, helps teams sort these things out. I know that in practice, it involves a lot of skill to guide a team through those phases.
> the components of motivations in pretty much any other fields are autonomy, mastery, accountability
You are absolutely right. If you read through the Scrum guide, you will find all those aspects in there. I think what you are describing, though, is how Scrum is "lived" in many organizations, which have difficulties empowering teams and provide the environment necessary to do Scrum.
In these situations, the answer is often that Scrum simply don't work, it's clashing with your culture and structure. Many teams opt to implement parts of Scrum - which is fine and might work exceptionally well, but it's not Scrum.
They might not meant it, but that is what it creates. It does not create empowered workers. It does not even talk about people or individuals, it is always team. But "the team" does not make decisions, individuals do. There are emergent decisions, coming out of the system, but no empowerment to anyone (maybe except PO).
> Following the values of Scrum, respect and openness in particular, helps teams sort these things out. I know that in practice, it involves a lot of skill to guide a team through those phases.
"Respect" helps to solve conflicts in literally any kind of methodology. And healthy asertivity too. That does not make Scrum special. It still makes it harder then other methodologies. It still leads to harder and more emotional conflicts. Probably because people with no feeling of control are fighting over control
> If you read through the Scrum guide, you will find all those aspects in there.
That is not true. Scrum does not give any agency to people working in team, only to "team" as a collective entity. People working inside the team work at 2-4 hours long tasks at maximum, all the problem solving was done "by system". Individuals are not improving, except in following the process.
I actually wrote a comment recommending the same book, but might as well tuck it here.
Mise-en-place is well designed but much of it doesn't translate well to knowledge work, which is why these books aren't more popular. It's still a great addition to your toolkit and sometimes when I'm overwhelmed, I remind myself to keep things clean and just finish stuff.
It allows the community to grow, learn and become more diverse.
On the other hand, I regularly read blog articles about complex topics from people that should rather not write about it. I know "senior software engineers" where I ask myself how they are capable of tying their shoes each morning. I see people get praised for achieving the bare minimum, like putting five pictures on LinkedIn about a topic they hardly understand at all.
Others will talk about the benefits, so let me give you a few gotchas from us:
1. It does not replace type checks at runtime (in integration layers)
2. Compilation and startup (in backend land) is slow
3. Some tooling seemingly caches (webpack? ts-node?), we regularly run into situations where rebuilding locally works but then building for prod fails with type errors
1. You can deal with this with stuff like io-ts or runtypes. I strongly recommend either, though I use runtypes myself. Defining your objects in runtypes and having it implicitly return types for use elsewhere in your application is awesome, and it even works with branded types.
2. Yes and no. It's not the fastest build out there but if you've enabled incremental builds it's quite quick unless you're touching heavily related-to code (libraries that are imported all over the place). If that's not fast enough for you, I've seen people having very good success with `swc`.
3. I can't speak to webpack, but ts-node shouldn't be caching anything last I looked at it.
2. esbuild has support for TS (it strips the type annotations out during build), and is plenty fast (compared to webpack, rollup etc). So bundling itself should never be an issue. The other aspect is type checking. If you want TS to type check your project, then yes it takes a bit of time. But that's no different than running tests. Of course running those will take some time. Once the project is bundled, the startup time should not be affected at all, it's all JS anyways.
The thing is, though, that Typescript is not solving runtime type checks. Typescript is declarative, it does not check at runtime and if you have any code interacting with third-party data sources and you do not check there, things will explode down the line.
I half agree with your response. It's true that third-party data sources need to be validated using runtime type checks, whether in explicit custom code or through some schema validator framework. But TypeScript is very helpful in the common case where the caller is fully typed, so the callee doesn't need to do all the needless defensive checking.
