Lessons in Agility (part 1)

I recently was following a post on LinkedIn on someone trying to recruit a developer to their team. What a learning experience it was. I am sharing the experience and how this hiring process make sense from an organizational context in this company.

The company I am talking about is Gusto. And here is an extract of their job posting so that we can talk about the elements of this post.

Let's start with the day-to-day expectations:

• Own what you build - while you architect, test, refine Gusto's Product suite - the position starts with absolute ownership, not passing the buck from one role to another, or passing the buck to someone else to complete. The developer is responsible for architecting, testing and improving the organization's "Product". And that is remarkable. When you "own" something, you are responsible for it. When you are truly responsible for it, then it leads to engagement.  No wonder your organization has poor employee engagement scores.
• Tackle code problems throughout the stack and product code base - collective code ownership with individual responsibility to contribute. Again, no passing the buck. If you organization is built on control and lack of trust, then no wonder you are not having ownership for tackling code problems.
• Collaborate with Product Management and Design teams - Collaboration is key. And it suggest collective ownership along with Product Management and Design teams. Again, not a throw it across the wall. Most organizations have siloed ideation and design with no involvement of developers in "Design" - how Agile is that?
• Prototype, iterate and launch daily - Build, test, launch. And the developer is responsible for it. As you prototype technical and user experience design emerges. By working with Product Management and Design guideline teams. And Design guidelines improve, evolve and get updated. Every day. No two week Sprints. No twelve week program increments. And "Launch" is to customers. As quickly as possible. How fast is your process? Rings a bell. The customers are ready. Have been for a long time. You can see that in our own cell phones where apps update every day. And "we" the customers figure things out. Fast. The days of 12-week cycles followed by another 6-week launch and stabilize are long over. Perhaps in the 20th century.
• Build products that our customer generally love - each "Product" developer is responsible for products that customers love. Simple. Isn't it? But complex for you, because of the disjointed and human-less way that your organization of robotic widgets are setup.

And this list of what a developer does day-to-day at work is just a start... we shall delve into more tomorrow and what it takes to make this work and why it wont work in your organization's context... Await Part 2 tomorrow.