„what a stupid question”
For me, it is much easier to work with someone, if I assume that the person on the other side is competent to do the job, but sometimes does not have a critical piece of information. This information is often obvious to me, but missing for some reason, to the other person.
When working on a globally distributed project I found that every time, when someone from my team was appalled by a „stupid question” from the remote office, it was the missing information scenario. Sometimes it was the other way around and we were the ones with the missing information, while the remote office thought it should be obvious for us. In such case, the question didn’t seem to make sense. What I learned to do, was to provide the best answer I could without understanding what is going on, but immediately after that, ask the remote office an easy question: why are they asking about that? Turns out that every time they had a good reason.
Often our willingness to answer the question instantly changed to a top priority.
Quite often after we understood the background of the question, our answer changed 180°.
Parallelization in digging ditches and software development
There is a saying: 9 women can’t make a baby in a month.
This carries some meaning in software development, but it is difficult to relate – building software is very different from making babies. I heard a different version of this, called a „mathematical paradox”:
If you give a man a shovel and a goal of digging a cubic meter of dirt, he can do it in 6 hours. If you get 6 men and 6 shovels, can they do it in one hour?
Seems like easy math, right?
As it turns out that the answer is no – they would accidentally kill each other when swinging their shovels.
If you are building a service which needs to scrape information from 10 sources, it is fairly easy to parallelize, you can split it into multiple developers. That is because you are actually digging 10 separate holes in the dirt (around the same area).
However if you are working on something very dense, using many software engineers / construction workers can actually slow down the process.
Dear reader, it is now time to take 10 seconds to reflect on how this applies to your project. You know which one I am talking about. Yes, that one 🙂
10 seconds, starting now.
Imagine you want to file a bug in Jira. You click „new issue” and a form with a few tabs opens. Count the fields – there are more than 200 in total. You are forced to fill this thing properly by the organization.
Welcome to jira hell.
This sometimes happens, because the person in control over Jira configuration adds fields without fully understanding the consequences. Sometimes there are multiple administrators, which can lead to duplicate fields. In one project I found three fields for the same thing. My friend found dozens of fields which had an empty value in all issues – someone added those because he thought they might be needed. We don’t know who.
I’ve seen one field which had a red, bold text just under it, saying „you must fill this field!” or something like that. It sounded serious, but my team never filled it and, strangely, there were no consequences. That struck me as odd. If it is so important, not using the field must have some negative impact, right?
I decided to find out who added this field. That took a while, but the person said that it was needed in a past for analysis which has been done over the course of 6 months and was completed (terminated!) a year ago. Field or the red notice were not removed. Also, this analysis did not involve my team (there was no appropriate value to select from the combo box for what we did). As far as I know, until this day, every other team in the project is carefully filling this field for every issue that they report.
Think twice before adding a field to Jira. It is a serious decision with a long-term impact on many people.
Why does IT need HR?
Apparently the list of things HR deals with is sizeable:
- Reporting to authorities
- Occupational safety
- Work time management
- Works councils
- Union collective agreements
- Benefits (non-monetary „salary”)
- Total compensation
- Travel policies & reimbursments
- Merit money
- Travel partnerships
- Keys and id cards
- Soul doctoring
- Policies, processes, practicies
- Mandatory trainings
- Development of managers
- Employee branding
- Events coordination
- Employee/union negociation
- Learning & development
- Employee performance
- Employee development
- Merges & acquisitions
- Due dilligence
- Gender equality
- Social media (for employee branding)
- Expert/distant workers
- International project policies
- Help with organizational changes
- Employment planning & budgeting
- Tracking headcounts and FTEs
- Senior management contracts
- Leadership support
- HR IT systems
- Metrics, analytics & evidence-based decision making
- Employee surveys
- Tracking employee contact information
- Org charts
Could software developers, scrum masters, product owners, managers or CEOs do all of that? Maybe they could…
But why would you make them?
On hiring software developers through recruitment agencies
From what I’ve seen, the entire effort of a recruitment agency is:
- Gather requirements for the given position from the customer, put it in a Word document (takes maybe one hour)
- Send it to a recruitment portal, paste an excerpt on LinkedIn (takes a few minutes)
- Pretend to process the CVs that people send, for example by calling each person and asking how much money they want. 3 questions tops, so that it does not filter too many candidates (takes 15-20 minutes per candidate)
- Forward the CV to the customer (few minutes)
For doing the above they collect between 10% and 25% of the yearly pay of the filled position, at least where I come from. Could the client have that done the same by using internal resources? How do you think?
Attentive reader will observe that if the candidate demands the exact top of the budget the commission will be maximized for the recruitment agency.
Think about that next time an agent asks you about the budget.