DEV Community: Jinsy Oommen

The 5 Dysfunctions of a Software Team

Jinsy Oommen — Sun, 25 Aug 2019 20:03:20 +0000

Over the past fifteen years, I have worked with some amazing teammates, but sometimes, we struggled to ship. Not shipping features is very demoralizing to a software team and it corrodes the product and team cohesity. Even though all of the individuals within a team might be capable and extremely productive individually, there might be some factors that cause us not to ship when we get together as a team.

As part of an assigned reading for a team I was on, I read the Five Dysfunctions of a Team by Patrick Lencioni. He frames the dysfunctions as Absence of Trust, Fear of Conflict, Lack of Commitment, Avoidance of Accountability, and Inattention to Results. From my experience, I found software teams to be more nuanced in their productivity and output and I found it helpful to reflect and define the dysfunctions of a software team with more specificity.

Lack of Technical Leadership

Decision paralysis can set in when there are many things on your plate and you need to pick a direction. A strong technical leader can help facilitate the decision making process and own the decisions that have been made. Teams also need to be constantly aware of the technical vision. Individual contributors can and should have tunnel vision on what they are working on, but it is important for them to have direction when they Need it. An effective technical leader can also help communicate the need for and importance of sustainability and technical maintenance of the product to the stakeholders.

Lack of Product Definition

A default state for developers and individual contributors is bettering the product through working on maintenance or trying out new ways to improve developer experience. This is great, but can demoralize the team eventually if it is not balanced with features that provide business value. When the business path of a product is not well defined we also may have the tendency to fill our backlog with not-essential-to-the-business features. This could cause users to not engage with the product, leading to not enough feedback and eventual disengagement within the dev team. Not having proper product definition could also lead to too many pivots in the development cycle, which in turn can contribute to the feeling of never finishing a project.

Lack of KIND and Deliberate post-mortems and incident reviews

Incidents are inevitable and I would even posit that they are a sign of progress and change. If we are not deliberate on conducting the review without assigning blame, we could go down the slippery slope of not learning from the incident, prevent us from team accountability, and keep us from owning the entire lifecycle of the feature. This can contribute to a culture of fear of failure, thus never trying new things.

Failure to Embrace Automation

Not embracing automation of process, deployment, and release can lead to tedium and release fatigue. Not automating deployment and shipping puts an easy target on the developer’s back leading to blame when something defective gets shipped. Not automating process and standards can lead to time unnecessarily spent on nitpicking and bikeshedding.

Lack of Defined and Documented Process and Rhythm

We are creatures of habit and look for rhythm in our professional lives. A productive shipping team has purposeful process and a rhythm that is sustainable for the team. For some teams this may look like weekly cycle and for other teams it maybe a 6 weeks, but it is important to have that rhythm.

I used to think being productive had mainly to do with our tech stack choices but experience has led me to believe it is more nuanced than that. I think I can say this on behalf all developers that we are content and happy when we ship something that make our customers happy. It takes a village to create and sustain an impactful product.

Spaces

Jinsy Oommen — Sun, 21 Jul 2019 16:48:00 +0000

That second look

Not because I'm extraordinary

But because I look different

I take up space in your world

You want to contain me

Within spaces you don’t occupy

You like me from afar

But not all of me and what makes me

I am learning to push back

Though I'm at ease where I am

Dismantle the wall brick by brick

If not for me, then for those who come behind

13 things I learnt in my first year leading a software team

Jinsy Oommen — Sat, 13 Jul 2019 13:51:33 +0000

About a year ago, I moved into the role of a tech lead on my team. For some background, I work on an embedded software team within a larger Energy Efficiency Consultancy organization. Embedded Teams function very differently than teams in larger software organizations. You will be required to wear multiple hats, process will have to be built from ground up, you'll have to be very mission oriented, and you'll have to learn the business. I learnt a lot along the way, and I am grateful to my team for giving me space to grow and learn.

1. Context is everything

People like being part of a greater mission. One of the ways to reiterate your company's mission is by providing context for everything your team will build. Over-communicate your roadmap, bring up your quarterly painted picture regularly. Connect stories back to the bigger picture. Connect stories to problems it could solve in your business domain.

2. Manage up

As a Tech Lead, you have the opportunity of expanding yourself beyond the stories that your team works on. You have a chance to anticipate business needs or see places that need process improvement. Freely share your learning to your peers.

3. Document your decisions

Decision making is tedious, and you may encounter decision fatigue. Document these decisions and make it freely available to your team.

4. Be selective of your advisors

A lot of the advice for software development and management process is from a perspective of a company providing solutions purely through software. Be aware that sometimes it is harder to scale down advice than scale up. Read all the blogs/books you can, but do reflect on what works best for your team.

5. Be your team's biggest advocate

Get to know your team in a professional setting, through regular 1:1s. Get to know their interests and how you can help them grow their career. Be a coach and a mentor. Recognize the value that each member brings to the team and give positive feedback generously.

6. Provide direction but let your team be autonomous

Don't feel like you have to control every part of the software development lifecycle. Provide a framework where decisions can be made without fear of failure. Things can go wrong, but that's OK. We'll move on and learn from it.

7. Read code and participate in code reviews

You may not be able to contribute to sprint cycles regularly anymore. Keep in the know by reading code that is being written and merged to production every sprint.

8. Do some spikes

You do have the opportunity as a team lead to look at the bigger picture. Go ahead and do some spikes. Try various architectures, so you can help make informed decisions.

9. Engage in customer support

Delight the customer. Put yourself in regular customer service rotations to gain customer perspective and understand their pain points.

10. Broaden your skill set

Now is the time to go broader on your T-shaped skill sets, rather than go deeper. Read generously about developments in the industry across your full stack.

11. Learn about your business

Become a business domain "expert". This will come in handy when you have to provide context to your team.

12. Talk less, listen more

Folks who speak the most benefit the least. Foster innovation on your team through a culture of knowledge sharing and brainstorming.

13. Don't be afraid to fail

Go forth and fail, rise up, and learn. Be a kind, empathetic human being.