As others are saying, ideally the worker income class would allow for parameterization of the constant, making this class independent of that value.
Ultimately, the calling application might also allow for parameterization in terms of external configuration (e.g. a file). Once we have external configuration, we can change the tax rate — though consider that if the configuration file is read only once at startup, then the application will have to be restarted for updated tax percentages to take effect, so that is something to keep in mind. We could provide an application feature to reread the configuration when directed to do so, or we might provide a more complicated mechanism that notices when the configuration file changes...
Long term, you may find that the tax issues require more than just a percentage — for example, that one day the tax laws are more complex and requires several percentages and some constants (e.g. the amount under $10k taxed at X%, while the remainder taxed at Y%).
This basically suggests using a strategy pattern, where the main class in question here accepts a strategy object for computing the tax.
The various strategies (and %'s and $ constants) should be choose-able from the configuration file, and now, adding a new strategy requires adding some new code, but not necessarily updates to existing code.
Each strategy might know how to parse/interpret its own external configuration arguments, along with how to compute actual tax.
Dynamically, the tax may further depend on the governing locale, so you might have locale associated with earnings or with employees (or both). In external configuration, we might associate locale with tax strategy.
Also see dependency injection, where we manage these things explictly.