1. Clarity
What does success mean?
- Are you working on the right problems?
- Would your VP/Director/CEO be interested in your work?
If the answer to any of those questions is no, then why are you doing all that work?
If yes, great job! More questions!!
What are the secondary and tertiary goals of the work? How can you achieve a larger impact via strategic leverage? Don’t settle for less, think two steps ahead (just like in strategic games). Think of collaborations or proactively reaching out to other partners for reuse and idea fertilization. Think some more.
For Individual Contributors
- Does your work help your organization achieve its goals?
- Does it help the organization acquire more customers?
- Does it help with retaining existing customers?
No again? Then are you working so hard? What do you want to achieve?
Feature vs Value delivery
Over the years, I have worked on teams and seen engineers deliver features at incredible rates. Sadly, that intense focus on feature delivery can cause teams to prioritize feature development over value delivery.
Can a business be successful by shipping features that no one wants?
Features are invaluable when they deliver value; so aim to delight your customers so hard that they whip out their checks and write numbers with lots of zeros. I like big fat checks.
Leads should think hard about the needle they want to move when they plan features. If the goal is to acquire more customers; then that feature cannot be considered done until those customers sign up. You go back to the drawing board to understand why the hypothesis failed and run more experiments until you achieve your metrics.
This also applies to engineers: is a feature done once it has shipped or is it done when it moves the right needle? Real user feedback is a thermometer for measuring the pulse of the market. Speak to customers – you’d rarely go wrong relying on hard user input. The lean startup’s Build-Measure-Learn approach is a great framework.
Before you pick up that next project/feature/work-item, think about the needle you want to move and define what success looks like.
2. Safe Ownership
People don’t like being judged and might withdraw into their shells after such encounters. I personally have not found harsh criticism to be effective at boosting code quality.
On the other hand, allowing people to safely make mistakes and learn is essential for growth. No one enjoys being under the spotlight for a mistake and humans will keep making mistakes.
Put a focus on why things went wrong and try to fix that – that could be via process changes, automation or tooling. More importantly, the process of learning should be as open and inclusive as possible: we need people to speak up so that the underlying issues can get addressed.
Ultimately, almost everyone is trying their best.
Do engineers feel safe to own up to mistakes and work on preventing future re-occurrence?
3. Continuous Learning
Does your team have a learning culture? The chasm between learners and non-learners grows exponentially. Learning constantly will expose you to new ideas, equip you with deep analytical skills and enable you to avoid the mistakes of others.
For managers and leaders, ask your reports about their learning and growth in your 1:1s. That way you foster a learning culture and simultaneously get to learn something new too!
Another tip is to mention personal growth in squad retrospectives: setting that expectation of constant learning helps everyone to invest some time in improvement. It also compounds fast and empowers new team members.
What should you learn? Anything: keyboard shortcuts, language features or new tools. Just keep learning and sharing!
Are you better than last week’s version of yourself? How have you grown?
4. Razor Focus
Is your team working on too many things at once? Here are four symptoms that might help you identify such.
Does your team attempt to deliver 100 features every sprint? Why?
If your team exhibits the following symptoms, then maybe you need to improve your focus and cohesion.
- The number of in-progress work items is very close to the number of engineers on your team.
- Engineers work in silos – they work solely on an independent big multi-sprint effort.
- Disjointed stand-ups because of little work overlap. Ever felt stand-up was just a status update meeting?
- Work can grind to a halt if some folks leave the team.
Do you see such symptoms in your teams or teams you’ve worked on in the past? Here are some benefits of limiting the amount of work in progress.
- Value delivery: constraints boost creativity. A hard limit on the amount of work in progress will force you to critically invest in only the highest priority things. See Clarity.
- Reduces distractions and unplanned work: Having way too many things running simultaneously means you are prone to unexpected interactions between complex moving factors.
- Cohesion: The team gets to jell as everyone collaborates; new members learn via osmosis and cross-fertilization of ideas leads to better designs.
Software development can learn a lot from the manufacturing systems and practices (e.g. Kanban, lean manufacturing and TQM). There is a good reason behind trying to consciously limit the amount of work-in-progress.
Early in my career, I would try to boil the ocean. I had an eye-opening experience last year after an interaction with a high-up manager. Now, I try to make strategic bets and execute vigourously.
Leaders should spend a lot of time thinking on their big bets. Ponder deeply on the investment, identify the big bets and then go all out to deliver at 200% value. If you are going to narrow down to a small set, then you better knock it out of the park.
Do you have too many irons in the fire?
5. Processes are not Goals
Don’t turn the process into success itself!
Processes are ‘catalysts’ that help you hit your team goals; they are not goals. By all means, adopt them if they help your team to achieve its goals but please do not redefine success as the level of process adoption.
This is a common theme I have seen over the years: teams deprioritize customer asks because their perfect process constrains them. Do customers really care about what process your team employs? I have found out that some process is necessary as teams grow to bring in some structure and ensure some goals are met predictably and accurately. But don’t invest 10% of your teams effort into process grooming and cultivating if the ROI is not more than that.
The goal of software development projects is to deliver value by scratching a real itch (working software, effort reduction, cost optimization etc). If your only goal is to use some newfangled software development process, then maybe you have too much money, too much time or both.
Deliver value: if your team is more successful using waterfall, then do it!
Is that process more important than delivering true value?
Be deliberate, be conscious, grow…
CodeKraft 