Support Operations is pretty much a regular software engineering team. There are a couple key differences which are important though. Firstly, as the manager for the Support Operations team, I have control over both the prioritisation of work and the engineering management; we are very good at understanding where business priorities lie and what will lead to the biggest impact against our metrics. Our work is heavily focussed on breaking constraints; whether this be providing better tooling to automate debugging for a new product or more intelligent market segmentation tools for our Marketing/Sales teams. The metrics I prioritise against usually come down to either lowering business costs, decreasing churn or increasing revenue.
Secondly we have very good flow without over-working people. We have a very large focus on reducing WIP (Work-in-Progress) in the team and there's a heavy focus on having a start-it/finish-it culture. I learnt about the importance of this when I worked in the automotive industry and was introduced to Japanese manufacturing systems like Lean and TPS. Unfortunately a lot of these systems/techniques have been misunderstood in the software engineering world; where Kanban was originally created as a mechanism for reducing WIP, it's now often misunderstood globally as meaning solely having a "Kanban board" to track work. I've been very keen to insist that Support Operations at Cloudflare does not treat it like it.
For engineers, the workflow closely resembles Extreme Programming; we have short iterations (with manageable work) and a heavy focus on automation in the software lifecycle itself (beyond the bread-and-butter things like Test Driven Development, we are also thinking more and more about practical implementations of Search Based Software Engineering). We are able to deliver phenomenal value whilst having the space to work on interesting problems.
We aren't closely bound to particular languages or tools - with the focus instead being on having clean, testable code that delivers value.
I would very highly recommend reading The Goal by Eliyahu Goldratt. Although about manufacturing instead of engineering, this book had a substantial impact in how I look at leading an engineering team. I insist everyone joining the team reads.
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.
How do you approach Support Operations at Cloudflare? What do you find to be the most useful data to track and tools to use?
Support Operations is pretty much a regular software engineering team. There are a couple key differences which are important though. Firstly, as the manager for the Support Operations team, I have control over both the prioritisation of work and the engineering management; we are very good at understanding where business priorities lie and what will lead to the biggest impact against our metrics. Our work is heavily focussed on breaking constraints; whether this be providing better tooling to automate debugging for a new product or more intelligent market segmentation tools for our Marketing/Sales teams. The metrics I prioritise against usually come down to either lowering business costs, decreasing churn or increasing revenue.
Secondly we have very good flow without over-working people. We have a very large focus on reducing WIP (Work-in-Progress) in the team and there's a heavy focus on having a start-it/finish-it culture. I learnt about the importance of this when I worked in the automotive industry and was introduced to Japanese manufacturing systems like Lean and TPS. Unfortunately a lot of these systems/techniques have been misunderstood in the software engineering world; where Kanban was originally created as a mechanism for reducing WIP, it's now often misunderstood globally as meaning solely having a "Kanban board" to track work. I've been very keen to insist that Support Operations at Cloudflare does not treat it like it.
For engineers, the workflow closely resembles Extreme Programming; we have short iterations (with manageable work) and a heavy focus on automation in the software lifecycle itself (beyond the bread-and-butter things like Test Driven Development, we are also thinking more and more about practical implementations of Search Based Software Engineering). We are able to deliver phenomenal value whilst having the space to work on interesting problems.
We aren't closely bound to particular languages or tools - with the focus instead being on having clean, testable code that delivers value.
I would very highly recommend reading The Goal by Eliyahu Goldratt. Although about manufacturing instead of engineering, this book had a substantial impact in how I look at leading an engineering team. I insist everyone joining the team reads.