Crazy idea – let’s drop divorce rate using Agile

It made my month to be able to facilitate agile team chartering for a couple of amazing teams at my work.

What the hell is “team chartering” you ask?

Team chartering is a proven technique in Agile framework for building team alignment, effectiveness and cohesion.

Whenever a team undergoes a major event (team formation, team members joining or leaving etc), the entire team gathers together and holds the chartering meeting (also known as the kick-off meeting). The goal of the meeting is to establish alignment around team’s purpose, clear role definitions and responsibilities, working agreement, communication methods, stakeholders, shared team values and other similar things.



When I first proposed this the devs on my teams were skeptical. “It’s a waste of time, we should be working instead of spending time in meetings” – was the common sentiment. A few of the developers felt this was incredibly childish.


Oh how their tune changed after the chartering! The teams emerged invigorated, excited, and aligned around a crystal clear vision. They soon established themselves as highly effective teams, delivering quickly and delighting their customers. They later recommended this exercise to many other teams.


So one day I was watching a married couple fight over small stuff on TV and I had this crazy idea – what if we required team chartering for MARRIAGES?

Marriage is a team sport after all . 

Imagine couples were required to explicitly discuss and agree (or agree to disagree) on their core values before the were allowed to marry.

Imagine they were required to provide a working agreement detailing out how they will approach conflict, what is an acceptable and unacceptable behavior towards each other and how decisions will be made.

Imagine they were required to discuss and agree upon communication – for example, how would they give and receive feedback?

Imagine they were required to provide a working agreement on how they would handle their money – nest egg, daily expenses, and emergency funds.

Imagine they were required to identify ways in which they would support each other and help each other grow.

Just imagine …. a marriage that starts with clarity and alignment, agreement and commitment via Agile Team Chartering.  And while we are on it – why not apply Agile mindset throughout the marriage? Frequent marriage retrospectives, reflection on how things are going and continuous improvement can’t be a bad thing, right?

What do you think – crazy stupid or crazy we are not doing it?


Team charter images source:

Who needs managers – our teams self-organize!

In the past few years Agile took over the software dev industries by storm. Most huge and massively successful companies implement Agile and swear by it. The “self-organizing teams” format seems to be the new de-facto way of running a business. The “Scaling Agile” article by Spotify and similar publications have showed us the way, and we gladly follow. I myself could not contain my excitement when I first found out about the concept.

However after talking to a couple of friends, all coming from amazing companies that implement this in one form or another, I started to discern an unpleasant pattern in this setup.  It’s not core to the idea itself, but rather to implementation details of the idea. The problem stems from the belief that self-organizing teams don’t need “traditional” managers since they are…well, self-organizing. Just let the developers pick what they want to work on, and allow them to manage their own processes, problems, priorities, work.

I’ll illustrate the problem using the story of my (fictional) friend Steve.

Steve has a dream, you see. As a young, bright, aspiring professional fresh out of college, he wants nothing more than to join this very successful Company that everyone – EVERYONE – would kill to work at. After all, this Company is famous not only for its major advances in its industry, but also for its culture. It allows its employees self-organize in teams, work on what THEY want to work on, spend a large portion of their time in hackathons,  and it doesn’t really care so much for deadlines or budgets. The Company’s org structure is very flat – in fact, they frown upon official titles.  It sounds like a dream – and for the most part it is.

One day Steve gets incredibly lucky – he is picked by his dream company over hundreds of other wide-eyed and excited candidates. When he joins the company, he is assigned to a team that, as Steve soon realizes, has a few challenges.

The team’s Product Owner frequently butts heads with the senior engineer Tim, and the rest of the team prefers to stay out of conflict and out of the way of these two strong personalities, and so they keep quiet most of the time.  Tim feels that the rest of the engineers on the team are “too weak” and so he doesn’t trust them to code – he does over 70% of coding himself. The engineers are not sure what the goals are, so they just work on their own things, or on emergent requests from other teams. The team doesn’t go to lunches together – everyone has their own “lunch crew” from their previous teams (people frequently move between teams at this Company). The team flies just under the radar of their project’s Product Owner because a) he’s busy and b) somehow the team continues to deliver small increments of value, usually due to heroics of nearly-burnt-out Tim who pulls frequent all-nighters (remember – he doesn’t trust other coders on the team to do the work).

Back to Steve… he has an assigned manger – a guy he has half-hour one-on-ones with every month. Because The Company firmly believes in 360-reviews and self-organized teams, it doesn’t feel the manager needs to spend any more time with Steve. In fact, they assign unrelated work to managers to keep them busy – so they don’t micromanage. The manager’s job is to help Steve draft his “Personal Career Plan” and make sure Steve is doing ok. This particular manager has over 30 other “reports”.

Steve also has an assigned Mentor. This Mentor is a very senior guy on a different project within the company, and he is very busy with… well, whatever it is, he doesn’t have an open spot on his calendar for the next three weeks. The Mentor also has scheduled once-a-month one-on-ones with Steve to mentor him.

At first Steve is at loss. He goes to a few team members and tries to point out the problems. Some shrug, some tell him not to worry about it. Others say that they tried to fix it and it’s now better than it was – baby steps, my friend! A few times he tries to interject between the PO and Tim, he gets caught in the cross-fire. Steve brings this up with his Mentor at the next one-on-one, but the Mentor brushes it off – Tim is a very well-respected engineer in the company, he surely has things under control. He tells Steve to seek further advice from Tim.  Steve brings this up with his manager, but the manager tells him that the team will sort it out – “we believe in allowing the teams to self-manage – we are an Agile company after all”.

Finally, inexperienced and new to the company, Steve gives up. He is now quiet during PO-Tim stand-offs, he primarily works on fixing bugs that a guys from QA assigns to him, and after a while he starts going to lunch with that QA guy and his friends. At lunch, he frequently bashes his team’s dysfunctional habits while the QA guys have a chuckle.

A few years later, Steve – now a solid mid-level professional – leaves the Company for greener pastures. He easily finds a job (because he has the Company on his resume!), and is much happier at his new place. He no longer believes in Agile.

I know it’s not fair to generalize. Steve’s experience was probably not reflective of a typical experience of a new employee at the Company. Likely those assigned to healthy teams have much better experiences. But I’ve heard this story enough times to think it’s a symptom of a persistent problem – not having proper management/leadership/mentorship support in place.

“Self-organizing” teams DO need managers (with the understanding that in agile framework, a manager = a servant leader).

  • A good manager will be involved in day-to-day of the team enough to be able to see and address the problems without micromanaging
  • A good manager will know enough of what’s going on to be effective in training and career growth of everyone on the team.
  • A good manager will demand high work standards, accountability and delivery which will keep team on track and motivated
  • A good manager will work hard with the organization at large to protect the team’s health by advocating low team members’ turnaround and less task switching
  • A good manager will coach the team on proper use of Agile methods and enable the team to mature and become empowered and effective
  • A good manager will have strong support network of his/her peer managers to keep him/her honest and provide learning and feedback opportunities
  • A good manager will have  a good manager of his/her own who is involved, accessible, experienced and has a very strong interest in success of his/her “reports”
  • A good manager will avidly subscribe to the “servant leadership” model and his/her primary goal will be to empower and grow (rather than “manage” his/her “reports” and team

I do love the idea of self-organized autonomous agile teams and subscribe to the model famously described in “Scaling Agile” article by Spotify. All I advocate for is that rapidly growing agile companies invest in a strong leadership/management structure to provide sustained and effective career growth support, team coaching and accountability. Please don’t hire more developers if you don’t have a proper mentorship/leadership/management support for them – it’s unfair to new employees and dangerous for the company. If your structure is layered (meaning you organize your teams into “teams of teams” around products, services or features) make sure that you have corresponding layered leadership structure. Yes it will look like (gasp) a hierarchy, but this structure will provide the glue necessary for self-organizing autonomous teams to be effective and work together towards the good of the organization as a whole.

Stop bitching, do this instead…

I lift my eyes from the computer screen to see our programmer Jim standing at the door. He closes the door and says: “Hey, I need to talk to you about something”. My heart fills with dread – here it goes again….

This has been the third time he came in to complain. He doesn’t like to use JIRA, you see. He likes to use Hansoft because that’s what he used at his last job. He really wants me to switch to Hansoft. He wants me to switch the entire studio to Hansoft. The studio that has been running on JIRA for years.

After he leaves, more complainers take his place. An artist who wants the lights off in the shared office, an Assistant Producer who thinks our feature delivery process is flawed, and so on, and so on…


Naively I was proud for a while that the team trusted me enough to come to me with their problems. In fact, I encouraged it. I thought I was creating an open atmosphere where people were free to express their frustrations without the fear of reprimand.

What I didn’t realize is that I was breeding an atmosphere of dependence. What was wrong?

  • The team became dependent on the manager to fix their problems. They came to expect it.  They got lazy in thinking through the solutions themselves.
  • It built a sense of entitlement. By listening to them and attempting to solve their problems I made them feel validated in their negative thinking and feel entitled to a fix.
  • It did a disservice to their career development by building bad habits. No boss ever likes to hear about the problems without also hearing about a proposed solution.
  • It made the team feel things are worse than they are. Rather than focusing on solutions, they focused on problems.
  • It discouraged team spirit. People get suspicious when they see their teammates talking to the manager behind closed doors.
  • It took a heavy toll on me. Listen to this complaining daily and you’ll start believing your team and your job sucks and everything is wrong. And since you can’t fix everything for everyone, you feel helpless at times. Hello, depression!

Once I realized what’s going on, I changed my approach.

No Complaining!

I now have zero tolerance for “empty” complaining. Instead, I promote the following.

  1. Understand the problem, its context, scope and history before bringing a problem to the manager. How many people is it a problem for? How did the problem come about? Were there attempts to solve it before? Why things work the way they work?
  2. Have a proposed solution.
  3. Think your proposed solution through. Are there any edge cases? Limitations (budget, time etc)?  How does it affect the rest of the team? What’s the cost (time, effort, money) of implementing it?
  4. Discuss the problem and the proposed solution with the team. Hear their ideas, have them beat on your solution and refine it until it “works” for everyone.
  5. Own the solution. There is a saying “initiative is punishable” 🙂 See the solution through, and enlist the manager to help facilitate it.

This approach has produced tremendous results so far. People on the team became more self-reliant and shown more initiative in finding and addressing problems. It brought the team closer as they solved problems together. It changed the outlook on their projects, job and teammates from negative to positive as they started focusing on solutions instead of problems. It built their confidence as they realized they had the power to change things. And finally, it helped restore my sanity as I no longer had to listen to “empty” complaints.

So my advice: discourage bitching and focus on solutions instead.

Life knocked you down? About to give up? Cowards do that and it ain’t you.

Remember that failure is always the first step to success. No matter how low you feel right now, your can always decide to get back up. Step by step, inch by inch, get back on your feet and try again. Because the true and absolute failure would be if you don’t.

Our deepest fear is not that we are inadequate. Our deepest fear is that we are powerful beyond measure. It is our light, not our darkness that most frightens us. We ask ourselves, Who am I to be brilliant, gorgeous, talented, and fabulous? Actually, who are you notto be? … Your playing small does not serve the world. There is nothing enlightened about shrinking so that other people will not feel insecure around you. We are all meant to shine, as children do. We were born to make manifest the glory of God that is within us. It is not just in some of us; it is in everyone and as we let our own light shine, we unconsciously give others permission to do the same. As we are liberated from our own fear, our presence automatically liberates others. – Marianne Williamson

You’ll never hit your career goals (if you don’t have them)

Dream it - Do it!

I’ve worked with Jim (name changed to protect the innocent) for over a year when he asked me for a career advice.  He was fairly new to the industry, young and ambitious. I knew that he would go far because he was smart, showed initiative and was not afraid of hard work. I also knew that he had multiple career paths open to him – and depending on the path he chose my advice on how to get there would be different. So I asked him – what’s your “end game”? Where do you want to end up?

He looked at me puzzled, then he said he didn’t think about it. He just wanted to advance his career, but he didn’t know what that career might look like.


Step 1: Define your career vision

“Whether you believe you can do it, or you don’t – you are right” – Henry Ford

Ever since my discussion with Jim the very first thing I ask people to do in their personal development plan is to come up with a long-term goal, a vision for their career. It does not have to be precise and it is guaranteed to change over time, but it needs to give you a sense of direction. Let’s say you entered the industry as a QA tester. You feel you want to go into production. Well, what exactly do you want to do in production? Do you want to work with engineers (technical producer)? Do you want to oversee art production? Support live online game? How about PR and Marketing? Do you want to manage people? Small projects or large projects? Do you want to be in charge of budgets? Do you want to be an Executive Producer? A VP of Production overseeing multiple projects at once? Do you want to stay in development or have influence over strategy of the products you work on? Or even – do you want to own and run your own studio one day?

Don’t make the usual mistake of setting your goals too low because you don’t believe you have what it takes or that you’re not ready. One of my favorite sayings is “whether you believe you can do it, or you don’t – you are right” (by Henry Ford).  The only reason you can’t achieve something is because you allow yourself to give up. So your long-term career goal must be pretty high.

Step 2: Figure out how to get there

Once you have identified your career vision, it’s time to start analyzing what it takes to get there.  This step in itself will strongly propel you towards the goal before you even realize it – as long you you are pro-active about it. As you scour the internet and the books for information on the role, you gain knowledge needed to fulfill that role. As you ask your superiors  about it, you plant a seed in their minds that you are interested in that career track. Next time they are looking for a person to fulfill a role along that career track, guess who they will think of first?

 Step 3: Pursue the vision, don’t pass the opportunities

Step 2 should create some opportunities for you, and if not, you should start seeking out ways to create those opportunities for yourself. Vocalize your desire to go along that career path to your peers and your supervisors. Ask for tasks in your current position that align with your career vision. Take classes if needed, attend seminars and read books. Find mentors that have the ability to not only teach you the craft, but also help you in your career by either promoting you directly, pointing out good opportunities to you or by creating those opportunities  (s.a.  recommending you to someone in their network).

The next big mistake I see people do (after setting the goals low) is not taking an opportunity when it presents itself. Usually it’s because they don’t feel they are ready to handle it. Here’s the thing – you absolutely cannot grow personally and professionally if don’t step out of your comfort zone. That’s how you learn. Allow yourself room for mistakes, ask advice and help, and do your best. You will surprise yourself.

The first few times you take on new opportunities, you will feel sick to your stomach with fear of failing, anticipation of unknown, self-doubt and worry. Force yourself through it. As you do this more and more, you will learn to appreciate the feeling and love the adrenalin rush of a new challenge. Soon enough, you will start seeking it out.

At the same time try to avoid moves that go against your vision. For example, I’ve passed on higher paying job offers in the past because they were not aligned with my goals and passion, and I have no regrets.

Step 4: Refine the goals as you go

 As you grow and take on new challenges, you may find that you are no longer aligned with your original vision.  That’s perfectly normal and expected. Reevaluate and adjust your career vision continuously based on your experiences and opportunities that present themselves.

Professional and personal growth is a lifetime journey, and it will be much smoother for you if your first step is to define which direction you want to be walking in 🙂

 “A journey of a thousand miles begins with a single step” – Laozi