If you're a successful engineering leader, scaling your team will naturally follow. The ability to do that well will dictate your continued success.
Having the right data can help bridge the gap between the dev leader and recruiter. "Our time to release is slow. We need more devops people to manage that process."
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
I've read it, it seems that you are doing some pretty advanced stuff at linear B :)
Now maybe I have an additional challenge for you.
Something I try and most often fail to communicate is how crucial learning is for programmers. I have lines like: "you know, programming is in fact easy when you have everything figured out. Figuring things out is the part that is hard. I think we should allocate time and money for experiments, learning, training and education".
I believe what I say but it's mostly my educated guess as a guy who has done programming for a long time.
Hard to communicate in numbers to C-level executives.
How would you tackle this - admittedly tricky - challenge?
That is a good challenge. The answer is probably more nuanced than can be captured in a comment board :) but I'll try.
Our community of users has reported that bringing metrics about their team on a regular basis build a new level of trust with the c-level, so that their requests for more "non-functional" or research work are better received.
Metrics can actually uncover areas of your process or teams that could potentially benefit from research time.
Metrics can also serve as a baseline to prove the benefit after the fact. For instance, "Before our research project, our cycle time was 3 days, but since we implemented the changes we found in the research, cycle time is down to 2 days. This means we can deliver faster."
Certainly lots more to discuss in this area. Let me know if you'd be interested in connecting with our team. Our co-founders were both former VPs of Engineering and have lots of experience trying to bridge the gap between engineering and executives. I can connect you with either of them, or you can visit linearb.io and click "Get a Demo" to meet with our team.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is such a great point!
If you're a successful engineering leader, scaling your team will naturally follow. The ability to do that well will dictate your continued success.
Having the right data can help bridge the gap between the dev leader and recruiter. "Our time to release is slow. We need more devops people to manage that process."
We wrote an article on scaling software teams a while back. Check it out: linearb.io/blog/how-to-scale-softw...
I've read it, it seems that you are doing some pretty advanced stuff at linear B :)
Now maybe I have an additional challenge for you.
Something I try and most often fail to communicate is how crucial learning is for programmers. I have lines like: "you know, programming is in fact easy when you have everything figured out. Figuring things out is the part that is hard. I think we should allocate time and money for experiments, learning, training and education".
I believe what I say but it's mostly my educated guess as a guy who has done programming for a long time.
Hard to communicate in numbers to C-level executives.
How would you tackle this - admittedly tricky - challenge?
That is a good challenge. The answer is probably more nuanced than can be captured in a comment board :) but I'll try.
Our community of users has reported that bringing metrics about their team on a regular basis build a new level of trust with the c-level, so that their requests for more "non-functional" or research work are better received.
Metrics can actually uncover areas of your process or teams that could potentially benefit from research time.
Metrics can also serve as a baseline to prove the benefit after the fact. For instance, "Before our research project, our cycle time was 3 days, but since we implemented the changes we found in the research, cycle time is down to 2 days. This means we can deliver faster."
Certainly lots more to discuss in this area. Let me know if you'd be interested in connecting with our team. Our co-founders were both former VPs of Engineering and have lots of experience trying to bridge the gap between engineering and executives. I can connect you with either of them, or you can visit linearb.io and click "Get a Demo" to meet with our team.