Guest lecture at DesignersX

Forward Looking Reflection

Every end is a beginning, if there is no end, then there is no beginning, just like the year 2023 can only start after the end of year 2022. So this is the right time to reflect and plan for a better beginning. This article is a takeaways from my recent guest lecture on key challenges of software development, and how the industry is trying to solve them.

14 min readJan 6, 2023

DesignersX is a company specialised in software development, located in the same city Mohali, Punjab, India where I started my career more than 18 years ago. They invited me to their year end event as a guest speaker and to interact with their developer community. It is great to see the development of city Mohali (which was then considered as an outer area of the City Beautiful Chandigarh), now it is well part of Chandigarh with extended beauty. The event was also beautifully planned, starting the day with a Paath, a spiritual prayer that spread a lot of positive vibes, and then a series of sessions and discussions, team events, and off-course with delicious Punjabi food. I must say there was no better way to end the year 2022 other than this event.

As my topic of guest lecture was on reflection, and finding the way forward. We discussed challenges of software development, and how the industry is trying to solve them. How can we make the right software in the right way? I asked the team to conduct a survey to reflect on the year 2022. The survey consisted of questions about their org health, project health, and personal front. The participants had provided good inputs for the actions for the future. They shared what is working for them, what things they want to improve, and challenges and hurdles they will try to solve in future as a team.

Here are some key discussion points.

Success, Growth and Satisfaction

Our achievement gives us a sense of success, and we tend to follow the same path that led us to that achievement. At times we may get biased with the way, and start ignoring other better possibilities. I have written an article on how “being successful” is better than “become successful” — “Change to become more successful”, this article was my takeaways from a book “What Got You Here Won’t Get You There”. So keep fighting to become more and more successful, but never try to stop at success. We are here due to our achievements or failures, but to grow further we need to look forward, and make an effort to advance ourselves.

Similarly people have their own criteria/parameters to define growth. Growth is always being represented upward and always relative to some past state, but in my opinion it is a journey and much more than just comparing two states. When I ask people about what growth means to you, your organisation and your client. I get answers as follows

and my take is “it’s all the same”, the growth is all linked, no one can get a real sense of growth without the growth of the ecosystem around us. So I just remove the lines and define growth as follows

Collective growth leads to better satisfaction, it is very important to define organization vision and make everyone aligned toward it. For example, look at ice-cream company “Ben & Jerry’s mission statement”, and how it inspired Thoughtworks in its early years and became part of its culture. Software is built by people, so go for sustainable growth by earning sustainability, achieving excellence, and work with social responsibility and purpose. It would lead to more satisfied and willing people, and may result in a better outcome.

Agile IT Organisation

Most IT startups/organisations want to be as agile as possible, requirements/needs are never fixed, controlling scope keeping it in limit is utmost important for efficiently and effectively delivering the software. During my discussion with DesignersX’s CXOs and developers, it came out evidently they are very keen to be a true agile organisation, and infuse more agility at various levels. ‘Agile’ means different to different people, and I feel it is the most overused word in the IT industry. I emphasised on improving reading habits of people, and gaining from masterpieces like Agile IT Organisation Design, a book by Thoughtworks, the organization I work in and admire for its ground level agility and people centric approach to solve challenges. Follow the industry agile pioneers like Martin Fowler, my colleague and also a co-author of Agile Manifesto. Be aware of Extreme Programming (XP) Practices, it may solve a number of IT industry and people challenges. Get ready for the need of the time, Async Agile that challenges some of existing traditional agile practices that we have gained in years of working synchronously.

What will work for a particular organization depends again on how well we understand the word “agile”. The idea here is to gain knowledge from others’ experiences and evolve from there, and define what works for you by experimenting and measuring the outcome. Try to solve a problem that is yet to be solved.

We also talked about Hierarchy vs Structure, Enterprise Agility and some of the takeaways at Thoughtworks that I shared here.

Being a Consultant / Consulting Org

Most IT people want to solve the problems at hand in the most optimal ways, however I feel many times they get trapped in the hierarchies or designations/roles they live in. If a solution is lying beyond their boundary they are trapped in then they miss the opportunity of solving it, no matter how capable they are of doing that. Consultants aim to do the right things in the right ways, then getting trapped in traditional boundaries.

Here some key areas consultant may focus on are as follows

Be a trusted advisor

Focus on creating influence and persuade others with the right guidance. Be a thought leader, and share your opinions, strengthen your voice with facts and figures.

It is important to identify the right problems in the situations, but focus on being on the solution side, the more we practice on finding solutions, we become better at finding solutions. The client comes to us not because they have some problem in hand, but rather they come to us when they think we will troubleshoot the problem well, and provide an optimal solution for the same.

Think of the problems as constraints, think of solutions with and without constraints.

Remember that for being a trusted advisor, you don’t need to be a subject matter expert(SME) of the problem area, rather you have to be a right advisor who may suggest the experts that may solve the problem at hand.

Autonomous Teams

A team of consultants who aim to provide solutions for the client, has to be autonomous, self-motivated. They are well aligned with the same goals and vision. They build a chain of effective delegation, and follow delegation as “Trust with Verify”. They first trust their team members, and verify frequently to enable them in getting things done as they anticipate.

Building a consulting mindset is most important to sustain and scale the team of consultants, and an environment of sharing with caring helps a lot. Focus on cultivating, mentoring and coaching. Read here on how coaching can enable self-reliance.

Strength based leadership and servant leadership are other key considerations that people centric teams. read here on strength based leadership in my reflection from a workshop. Think more on enablement, then questioning too much on people capability. Sometimes we ourselves don’t know our own capability, depending on the situation we may out-perform or under-perform a similar set of tasks.

Ownership

Sense of ownership plays a key role in building autonomous teams. Define ownership for outcome, and let them figure out “how to achieve” part.

I believe in team ownership, we succeed or fail as a team, not as individuals. Everyone is important and responsible for the outcome as a team, and to achieve that — trust, working together, supporting each other, upskilling, self-motivation etc comes as defaults in a team.

People focus on self sign-up, and encourage statement like

“I sign-up for this task” instead of “I assign you to this task”

Statement like following are highly discouraged

“I have done my work, and x person in team did not do the rest”

We work for outcome, and not for individual tasks, always look at the bigger picture. People start measuring productivity of individuals and question their performance as individuals, however as humans our productivity depends on the work environment, team, and culture and our own strengths. Every individual has their own strengths and areas of improvement. Ownership may or may not come as default with individuals, we need to mentor/train ourselves on it. As a team people need to own, and productivity is to be measured as team productivity (time to deliver an artifact) is most affected by slowest one in the team, so it is very important the other team members focus on uplifting the people and bringing them up to speed.

Measure what you want to improve on

We can improve a thing when we start measuring it, anything which we cannot measure we cannot improve there. So if we want to improve code quality then start measuring it first, if we want to be better in delivery schedule then start measuring it, if we want to improve the cost and effort we put into, then start measuring it against everything we do.

Everyone wants to improve efficiency and effectiveness of what they do, but most of the time we don’t give enough attention to the measurement. No matter how great processes we implement, if we are not measuring the improvements then it is like working in the dark. For example, timesheets — the friday/monday chaos, most of us don’t like filling the timesheets, and there is always a push required to do so. But we all want to better utilize our time and balance it in work and life. It is important we keep reminding people about the importance of measurement.

Measurement can be in the form of quantitative and qualitative metrics, depending on what is being measured. Over measurement can also be problematic and may lead to unnecessary effort being consumed, so measure what makes sense, and what can be easily tracked. Always keep “Why” before “How?”. Why do we want to measure? What do we want to achieve? Share the outcome upfront with all the stakeholders, and get buy-in. Then think on how? Choose tools and evolve as you go.

Faster Feedback, Faster Action

Feedback is really important for a consultant to validate and improve what and how we are doing. Collect and provide feedback as early as possible. Faster the feedback, more time we get to reflect upon. 360 degree feedback, frequent planned retrospection are quite important. Retrospect on

“what worked well or things I/we should continue doing” ,
“what did not work so well/things to improve/things stop doing”,
“Appreciations” and
“Questions and concerns”.

Brining feedback earlier in the process is called “shift left approach”; move feedback closer to the start. Testing and verification is also a form of feedback, the sooner we start testing and verification, the more time we get to plan the action. Vote for test driven development, automated testing; extreme programming practice to achieve shift left.

If one wants their team members/clients to improve/change, then the first thing they should do is share/receive feedback with clear context, and with reasoning on why it is important to act up on. Don’t assume that other people should understand what you expect from them, please communicate the expectation. Most issues come when we don’t set expectations, and communicate them clearly. Taking and giving feedback is also an art, ask clear questions so that you want to know people’s opinions. Another rule is to appreciate people in public, but when we need to correct them, have conversation in private.

Define your defaults

As a consultant/ or consulting org, define your defaults. When a person thinks of you, what comes as default? When a client sees your deliverables, what should they think as default?

For example, security by design, performance by design, clean code, agile team, zero tolerance to bugs, best user experience, innovating or what?

What are your default rules of delivery / execution — standard buffer / default estimation techniques, metrics, checklists, definition of done, definition of ready etc.

Agility vs Scope Changes

Many people think that “Agile” means accepting any change from a client at any time, and on that line they continue like this, keep trying to make their clients by burning themselves. In my opinion agility in software engineering never means to create more chaos and burn un reasonability. Rather it talks about change is inevitable, and better manage the changes, trying to move left and get faster feedback on what you are supposed to deliver, and plan what we can achieve in remaining time.

Consultants need to come with a change plan, and talk like “what best can we do in X time-frame?” rather “this needs to be done in X time-frame”. It’s all about scope negotiation, and consultants need to be good at it. Everything has a cost associated, no matter what is your delivery methodology — fixed-bid/ time-money someone is always bearing that cost. Some people say we don’t bother much for time-money projects as the client is paying on what they want, I strictly say NO to this attitude. In time-money risk of over-budget/effort is owned by the client, but does not mean we are not responsible for that, as we discussed in the start of this article that it is a shared ownership.

“Technical debt is real debt. It will eventually be paid by someone. And unless we take steps to hold companies and executives accountable for preventable — and foreseeable — failures, it will be we the public that keep paying.” — Zeynep Tufekci from linkedin post article

So manage the scope well, keep track of your bucket, if some things are getting added then other things need to go out, unless we may increase the bucket size, it’s a matter of prioritisation and negotiation. If time is fixed, and we need to deliver more than planned, then the only way to increase the capacity (and that too until a limit — adding more people does not always lead to proportionally increased delivery). Capacity may also be increased by improving the delivery efficiency, however if planned to deliver increased scope without increasing capacity that means we would deliver by burning people’s life. In such a situation people’s productivity is even lesser and we are more on the losing side.

It is also important to do pro-activity assessment of what we are planning, and review planned vs actual frequently, identify risks and plan for mitigation. Communicate the Risk, and mitigation upfront to every stakeholder. Keep it in the formal communication in the form of a document, or email, instead of just a verbal communication.

Continuous Innovation, Continuous experimentation

Tapping on the change or managing the change never means to restrict on trying new/ unknown things. Rather as consultants we need to focus more on continuously evolving and innovating. We need to try more without worrying too much about the failure, in-fact if we need to fail then plan to fail-faster, then later.

Celebate failures, just like what Amazon does and makes the successful failure, read here, the takeaways from the The book “Success Secrets of Amazon by Steve Anderson”. It talks about 14 principles that lead to amazon’s success. Not all the steps Amazon takes are successful or in-fact Amazon doesn’t take a step but takes a journey, which means continuous effort to make the way ahead. I have personally attended some interesting sessions at Thoughtworks internal event FailConf, and we collectively learn from our mistakes.

Prioritization — Important vs Urgent

Our plate is full of things to do, and everyday things keep adding to it. if we don’t manage it, then it will spill over.

We need to see where we are putting our effort, if we are always in chaos of doing things that are mission critical, then we need to think about our planning, we probably don’t spend enough on planning for strategic tasks. The tasks which are urgent but not important may be automated or delegated further, and the tasks which are important but not urgent, put time to plan them well, and pick them as time comes.

Conflicts of Interests

Since softwares is developed by humans, and wherever people work emotions, likes, dislikes, interests are bound to happen, they come from diverse backgrounds, culture, race. All this leads to bias or favors towards particular types of decisions. A group of similar mindset people also leads to influencing the decision in particular ways. It is always favorable to include people with diversity. As consultants we need to make right decisions — unbiased, uninfluenced from particular situations, avoid conflicting interests impact the decisions.

Try to collect inputs from a group by listening well to them and observing, and then filter out inputs that are too much influenced by personal emotions or bias. It is quite common that people with varied interests come as a team, but it is the responsibility of these individuals to maintain the decorum as a team, opinions are fine but don’t let your conflicting views come out, and add more people within your team on this side/that side. First think of the team, and then think of yourself, anything that is not in favor of the team’s interest is not in favor of you too.

This brings us to the end of the article, apart from the above points we also discussed on measuring happiness, ideations, team bonding events, open seating arrangements, project walls as the playground for brain exercises.

Conclusion

Every year we make resolutions, and we plan and execute some to reach closure to our targets, however unless we measure our progress we don’t know how close/far we are from target. That means we don’t know if we are going in the right direction, progressing there would be taking us to closer or far from the target, do we need to change our approach. That’s the conclusion of the session, we need to reflect on what we do, by measuring it.

“We can only improve the things that we can measure.”

Happy measuring! Happy new year!

Thanks Kulbir Singh and DesignersX team for making this fun-filled event, and inviting me to be part of it.