- Not sure if you did that on purpose, but you would say, "you need feedback", not making it plural
- I didn't like that the author is sort of mixing being a Team Lead with being a Manager. The role described in there is more of a Manager.
A great resource for Managers to be (and an article that is not trying to sell you something):
- I loved the anecdote on the Jewish census. Because I am always struggling to find examples about why sharing information might not be dangerous now, but it can be later, and you never really now.
I wish the article were about that, about what kind of information we are sharing in the present time, that may come to bite us back.
Here is my spin: Information can be used to your advantage (Relevant ads are good when they work), but it can also be weaponized (Oh, you search a lot for medical conditions?, maybe your insurance provider is interested. Or worse like we saw with Cambridge Analytica, "you seem to be democrat, let me see if I can bias you a little by hitting you where it hurts")
Here is my personal take on the situation from my experience: We are in a data collection period. Google, Facebook, Amazon, even Apple. Apple might be the worst actually. Silently amassing and hoarding data, researching the proper databases that can hold the data. We have seen things coming up in the last years like NoSQL, like Spark, massive analytical tools and real time databases. This is the equivalent of building a weapon.
Then the time of using that weapon comes. How? I wish I knew. I remind myself that we are just one CEO away of things being really bad. We are now under the shadow of people that grew in a different time, with a different set of ethics. Google still has the original founders on the board, Tim Cook is of the Steve Jobs school, Amazon is on its first CEO run. A few decades down the board, a new CEO gets appointed, and new CEO finds that he/she just inherited a massive data repository that can be used whatever he pleased. "Oh, we will never do that"? Sure, wait for the next guy to change their mind very fast, in the name of profits, or protecting a stock going down, or less strict ethics because they didn't live in the time where lack of privacy can kill you personally.
Sometimes I hold from sharing my thoughts, because people might label me as a conspiracy theorist :) But it is indeed on the back on my mind.
- This article would've been better with some concrete examples, or a study, or really anything to back it out. "Slack can be used for bad things". Well, so can email, mailing lists, support forums, internal chat systems (jabber), etc.
Not even one example, just "A lot of my CEO and founder friends talk about this".
As with any tool, it's how you use it. Best implementations I have seen of Slack is when the rules are clear for the beginning. Maybe channels are meant to be public and private is an exception, or the opposite (everything private to avoid noise). And clear guidelines. And to be fair, the discussion is usually a reflection of the company culture that is already present: formal, informal, direct. The tool just facilitates it.
- This can also be summarized as "Early on, don't be afraid of doing things that don't scale".
In this particular example, my "reset password" functionality could be sending me an email, and I have to reset the password manually and email you a temporary one that you can use. Bad solution? Yes. Doesn't scale? Of course. But if you have 5 customers it's not a big deal and you can use your time on something else.
The key here is to have good people in the team. A decent Senior Engineer / Architect would know that 'Reset password' will be needed. That is why a very technically solid person is gold in the first round, because they can design the signup in such a way that it's prepared for future requirements. They of course would also know that you can't store in plain text, that it should be hashed, that you might have to use a vault, that you need to randomize the hash, and that in the future limit access to the "user" table and never ever expose it through an endpoint where a user can reach it, as well as protecting against XSS and SQL injections.
Which of the list above goes off the list? There is a balance there in getting the right solution without scope creep, but also not implementing something so silly that it's going to get you into trouble later. The genius of a competent person is being able to tell what needs to be solved now vs. later
- True, but I think we can separate the idea from the person/company.
The problem statement is very well written. The Director of Engineering rotating because they can’t deliver, and the battle between Product and Engineering.
Conclusion is rushed, but it boils down to what agile advocates at the core: product manager and QA need to be in the room along with engineering.
It is until they hear daily about the challenges, first hand, and they see the struggle that it makes sense. Does not matter how many reports the PM does, first have seeing why technical debt is making things slow is invaluable.
Only addition I would add is: there is a reason why sprint waterfalls exist. You can’t iterate forever, and someone needs to play the role of the mature person that knows when something is good enough and needs to be shipped. I think Agile as a framework is at its limits. We need something that lets us run the engineering but at the same time becomes more predictable to business.
- Observe your team lead, he/she might be dead weight... or maybe not. It's true that a tech lead should be pro-efficient in the language and technology, but there are tons of things that a tech lead is supposed to do.
Bringing people together, keeping the motivation of the team going, solving conflicts as soon as they happen. Also communicating with management (maybe you haven't realized that you are free to focus on the tech side because someone else is absorbing the drama?)
A tech lead is also expected to be able to distribute work and keep everyone engaged, working through the process and making sure the team has the resources including QA, hardware, other teams, coordinating release schedules, aligning stakeholders, controlling scope creep and product managers. And sometimes the manager relies on him to even do admin work.
Sometimes people are in a position for a reason. The ironic thing that could happen to you would be that someday you get that job and suddenly realize that it requires a completely different set of skills.
What's hard is to interview for attitude and aptitude, and scaling that so other people know how to interview for those traits. Would you mind sharing some insight on what type of interview, green flags, things you are looking for, or process? Hopefully it's not only gut feeling :)