Sharing a post here https://medium.com/hackernoon/feels-like-faster-vs-makes-us-faster-828686facc7e

This blog post reminded me to write down my argument against using heavy process to do planning. “The Case for ‘Developer Experience‘” or full link https://future.a16z.com/the-case-for-developer-experience/?

This particular quote is my inspiratioin

So if I were to coin a law, it would be this: Any system of sufficient size and maturity will always involve multiple languages and runtimes. Software is heterogeneous, and until we as a community accept this fact, we’re upper-bounding how far we can get with developer experience. I call this The Software Heterogeneity Problem, and it has significant consequences for software development, management, and performance.

I’ve argued that building software is much more of an Art than Science. The teams who follow the agile manifesto strictly over plan this artistic endevor of birthing software from nothing with T-shirt sizing, rule of thumb and or fibonacci numbers in 2 week increments of a sprint. What I’ve observed in the real world of software engineering in 20 years is that during the planning and estimation process:

• engineers who are inexperience would over promise (under estimate) and work over time in order to meet their deadlines, thereby burning out or over time they learn to pad their estimates.
• senior engineers would know to pad their estimates by an order of 2X because they know from experience that they will encounter unknowns during implementation no matter how much time they spend up ahead to do story breakdowns.
• for all engineers, they are held to their original estimates (even though they are told they are not) so they try their best to deliver what they promise in the short 2 week sprint cycle. What happens with unexpected discoveries?
  • If they had to cut corners to make the delivery : They would file a technical debt for themselves or worst yet, for another team member, to fix later.
  • They are unable to deliver what they promised and the ticket gets carried over to the next artificial sprint. This is not a problem, unless the next sprint: the team decides their left over work is not a priority anymore and the cost of context switch in future sprints now becomes a huge mental overhead. Even worst if someone else other than the author has to take over the left over work

My recommendation for high performing software engineering teams is to try:

• Engineering managers: Build the trust with engineers, empower them to make smart choices.
• Give them the ownership of a feature over a reasonable long period of time (like 3 months or quaters) and trust that they will deliver what they promise.
• Give them the freedom do all the discovery, breakdown, don’t let a tech lead or anyone else do it for them
• Using the sprint structure for them demo, work and break down dependencies and a candance and milestone to check in
• Ignore sprint to sprint estimations (don’t do them at all)

Some disclaimer and background here

• I have been an individual contributor much longer than an engineering manager. As an IC I was part of a team of 2, back in 1990’s, and we built and deliver on the #1 website in the world with Yahoo! News serving 100 million users. As a team lead of 12+, we have delivered many production websites with unmovable deadlines such as multiple US elections. As an architect for 300+ engineers, we deliver on infrastructure and platform products for 130+ websites internally.
• As an engineering manager, I’ve worked on internal tooling without artificial deadlines, so my view could heavily biased.
• As an IC I’ve build tools that have endured with the highest NPS scores humanly possible at 81. The best tool I have built and my top engineers have built were don’t without the sprint structure.

What portion of your team’s time is spent planning vs. designing and writing and testing software?

Even when you did a great job in planning, how often is your plan exactly on target?

When you hit the target of what you plan after 3 months, is that plan still the right thing to solve?

My team recently had an idea for a metasearch engine. We had a vision document, explored different options to solve the problem, and then did a 2-day hackathon. With zoom audio, 4 engineers, and 43 pull requests later, we have a working prototype that answered these questions.

1. Is this a viable solution? – YES
2. What are the major components?
   1. React Front End, Vault security key storage, API multiplexer, Express routing server.
3. What are the unanswered questions?
   1. How does frontend filtering work for content? Does this really work to filter content?
   2. How does the UX work when thousands of content pieces return?
   3. How do we add analytics to improve the search results?

Our hackathon’s team outcome was that we learned to work with each other much better, intensely with 43 pull requests. The 4 people have a better sense of ownership and understanding of the technical and product vision. The team is much more excited to move forward with the next steps.

What we need to solve?

• How much to plan
• How to replicate the energy we had during the Hackathon
• How do we allocate more time for intense working

Each Of Us Has A Part of The Solution, Together We Have The Whole!

Splunk is a company of thousands of talented individuals, distributed across product development offices in 8 offices in the U.S., AUNZ, Europe, and Asia.

How do we do our best work collectively and continue to push innovation while expanding at hypergrowth rate?  How do we overcome the boundaries of timezone, physical location, and organization rigidity in order to create the most innovative products and solutions for our customers?

After working on Engineering Productivity at Splunk for the last 3 years, I struggled to understand WHY I chose which projects I devote time and attention to.  There was a common thread, there was something there to the madness.

The list of seemly random efforts all have some type of common theme that my beloved wife, Katherine point out this weekend when I ask her for her always piercingly accurate perspective.

Here is the laundry list of random efforts:

• GO URL Shortner – Community bookmarking
• Founding Engineer bootcamp – 6 hours of hands on workshops
• Founding #weekly-tech-talks – weekly tech talks for thousands of engineers
• Starting engineering book of the quarter – 2 books per quarter to every engineer
• Founding Friday Tips – Weekly technical tips from Tony’s perspective
• Starting #ama-[any person] and starting the first #ama-with-VP-eng
• Voice Of The Customer – Bring in customers to talk to engineers about use cases
• Founding and participated in numerous Slack communities (#bookclubs, #coffee-geeks, #badminton, #women-in-tech, #hackathons, #women-engineers, #noob-splunk-eng)
• Mentoring 8+ engineers (7 female engineers and 1 male) – Intentional choice
• Writing technical documentation on how to get things done
• Tools to enable engineers to publish, write more docs and be found
• Answering questions on Slack
• Founding of impactfulengineer.org – Inspiring Engineers Through Interviews With Engineering Leaders
• #eng-blog – public Splunk Engineering blog
• Bringing in world-renowned technical speakers
• Helping with really random questions from engineers (helping to advocate for a East Bay shuttle from Dublin to San Francisco)

In my next post, I will try to talk about the common themes I have identified

• Building Communities
• Working and Thinking In Open
• Continuous Learning & Growth Mindset
• Amplify and Leverage
• Diversity Leads To The Best Solutions
• Breaking Down The Silos

 

(The photo is one of my favorite pencils I borrow from my daughter. I finally used up all the lead in the pencil)

20 minutes, that’s all it takes. “Could you show me how you work?” Let’s turn on screen capture. Oh, interesting, what else? Why do you like this over, let’s say this other thing X?

Oh, that’s interesting you do it this X way. I always thought people doing it the Y way.