Layers of Work
My early attempts at leadership (mostly mistakes included)
If you're trying to build team trust with personality color tests or vulnerability workshops, I have some uncomfortable news for you.
If you've learned to delegate well, asking clearly, giving context, setting reasonable deadlines, but your team is still burning out, the problem probably isn't in how you're asking for work.
After years of building mobile apps, I've found that the most valuable analytics use cases are often the least obvious at first glance. The events that matter most are usually not the ones your analytics SDK gives you out of the box. They're the ones that help you understand silent failures, quantify technical tradeoffs, and recover data your backend model never thought it would need.
Have you ever felt the ineffectiveness of a team whose member you are? Have you struggled that the team’s decisions are not the same as yours and you didn’t understand that? Maybe you felt that all the team members point in different directions.
Have you ever wondered what we do as software development teams or what is our long-term purpose? Having such a perspective on why we do things as a team is extremely powerful but sometimes difficult to define.
Several times in my “leadership career” I heard an opinion that the team I lead is not “my team”.
Every development team that works with the product has a Product Manager. Sometimes it’s a Manager that works on a daily basis with a team, sometimes it’s a guy that catches up with the team once per week. Whatever the relation is this person usually tells the team what to do next and why it matters. Sounds familiar?
Supporting people's growth is probably one of my favorite team leader “duties”. When writing this article I’ve been a leader for more than 2 years and I must say, I’ve been doing it wrong for most of this time…