Categories
Agile Engineering Leadership Startup

Describe, Design, Decide, Develop – A framework for building things

estimated reading time < 5 mins

I was asked recently if I have any general advice on how to maximize product development success, and for such a big question, where do you start? There is so much to say on so many aspects, and I would have fun talking for hours, but figured it would be a good idea to consolidate my thoughts on it and then share them back. So I did.

Given such a broad subject, I have to limit the scope and not include

  • Business strategy (models) – good products tend to sell themselves but still requires more than just that, and although I have opinions on this matter, I will set aside for now.
  • A Career in Product Development – here, too, I have much to share and disagree on many aspects of path and education. Although what I share below could contribute project and individual success, it will not be the focus/intent.
  • Organizational structure – how to find, assemble, motivate and work with the right people to achieve the results.

Rather, I want to talk about an overall framework to increase your chances of successfully building something or at least getting started. Hopefully, it will benefit others, but it will allow me to make sense of the complexity or, at the very least, a good enough answer without having writing a book about it or sharing tons of links.

There are many frameworks, principles, tools, and practices in Product Development, but in my effort to synthesize, they point to these steps

  • DESCRIBE
  • DESIGN
  • DECIDE
  • DELIVER

Yes, it seems a lot of the good words start with D.

DESCRIBE – or define. In talent show terms – what’s the dream? What do you hope to accomplish? To the more informal – can you paint the big picture? To the more formal – what are your goals and objectives? Are there constraints, are those facts, and are they negotiable or not?

DESIGN – how are you going to accomplish it? Sometimes, there is more than one way to accomplish, and one is the best. Sometimes, there are no known ways to achieve the thing described, just ideas. What medium, what channel, what would the flow look like to reach the destination?

DECIDE – when you have many ideas and options, which ones do you choose? What if you chose wrong? How long should we think about it?

DELIVER – make it happen 

In coming up with this, I had three starting points

  1. In my experience and knowledge, what were the common causes of failures?
  2. I have always looked up to design thinking in building things – how does that fit here?
  3. In execution, I have always looked up to DevOps – how does that fit here?

What are some common causes of failures, and which steps might address it?

  • A failure of imagination = Describe and Design.
  • A failure in alignment – needing to be on the same page = Describe.
  • A failure in execution = Deliver.
  • Delays – inefficiency to Deliver.
  • Delays – untimely decisions (paralysis) = Decide.
  • Nobody wanted to use it = Design.
  • Not enough people want it = Describe (constraints)

It’s alright so far; improving on those steps could avoid some of these failure traps.

While looking further into the “not enough people want it” item, things come to mind: the product needs to have a bigger market, may be too expensive (pricing), or may not be well-known enough (marketing). The Describe step is broad enough to require a different design (strategy/plan) for pricing, marketing, and software development. A self-similar (fractal) pattern emerges, or a subset of the steps spins off the main path. For example, although towards the same described dream, you need a product interface design, an architecture design, a security design, and a pricing design, then for each aspect of those, you will have many options and have to make the decisions and deliver them. So this Describe->Design->Decide->Deliver (from now on also referred to as DDDD) happens in the bigger picture (e.g., business) as well as in the smaller picture (e.g., daily or task level). Or Describe -> spinning up 2+ Design steps in parallel the same way that Decide output could be status-quo and therefore Delivery is a no-operation. I have always thought and said that life is a series of decisions, but in more generalized terms, a series of these DDDD loops.

One description (dream) could require spin-offs of many aspects

Or in reinforcement learning king of way iterate on subsequent steps

So now what?

I want to avoid reinventing the wheel, but my goal of making sense of the concepts I have come across still stands. I will continue to test this framework until it breaks (by myself or as I get feedback from others). For example, the Double Diamond Design Thinking Framework involves “discover, define, develop, deliver” (again with the Ds). It overlaps with this a lot but does not seem to cover indecision or DevOps which I put a lot of stock on. It also has a different idea of developer+deliver. I will try to break this framework including seeing if this applies outside of software for my amateur woodwork, automotive, trading, or random house projects.

Assuming these are key/fundamental steps for developing something, there must be frameworks to maximize the success of each step, and I will explore those frameworks.

  • Describe – I am excited to know the good frameworks for framing things. I have yet to look much into this.
  • Design – I already love Design Thinking, so that’s more than a starting point for me here.
  • Decide – I have favored decision-matrix or grid/multi-criteria analysis unknowingly over the years, but there are tons of decision-making frameworks out there; it’s more than dizzying (OODA, TDODAR, Cynefin, RAPID, etc) and no shortage of acronyms but it will be fun.
  • Deliver – DevOps (DORA) might have more than enough to explore here.

Stay sharp, and keep building things! I will keep in touch.

Categories
Career Growth Community Engineering Leadership

First Principles, Frameworks & Guiding Principles

first principles, frameworks and guiding principlesWhen talking to other engineering leaders (new and even experienced ones – since every situation is different) it’s not uncommon to hear “this is great, your team/processes sound amazing but where do I really start?”.

“Where do I start?” is indeed a difficult question. A few clarifications and examples would help. We could identify a starting point and take it from there. There are also a lot of existing “how to do X or Y” everywhere online/offline so I am not going to talk about that here either.

I was thinking though, if I find myself asking the same question, what do I actually (or I think I) do.

So…. I believe I go through this process:
1- first principles (why)
2- framework thinking (how)
3- guiding principles (what ifs)

These are not my terms. The first one you can easily search (might even be in the dictionary) and Elon Musk (and others) has articles/interviews online that can explain it (or similar) better than me. The second one I did not find much except this article from Sean Johnson (http://www.sean-johnson.com/framework-thinking/) which captures a lot of what I had in mind. The 3rd one I’m sure we’ve heard everywhere.

To the best of my knowledge though even before I found out what they are called I have applied them in one way or another. Most of the time, if faced with a challenge; it is reasonable (maybe even best) to solve that problem specifically. In some cases, however, especially problems that keep coming back it helps to step back and look/think about it differently. What is the core of the issue, the root cause, the fundamental beliefs (or even facts) that my ad hoc solution did not address? And that to me is “first principles” – simple, fundamentals, facts (or as close as you can get).

Now that we have a better understanding of the “question/problem” there are frameworks that others have already used to address that. Or at least frameworks that I can try to explore more to address the problem. Frameworks are more generic than just how-to’s and usually can be applied to a variety of problems. Should I read books, do I listen to audio books, do I talk to someone and based on those are there further frameworks/techniques I can apply?

Using some (or combination) of the framework(s) we will hopefully find the solution to the problem and then we start building guiding principles. On top of making sure that it really does address your original question/problem, these also make sure that should you encounter similar questions in the future you might have some default response/actions or if it’s completely new then the response might just be back to square one (first principles -> framework thinking -> guiding principles).

Over time you build guiding principles that you keep on improving (or completely discard after giving it enough chance – i.e. it just doesn’t work).

First principles are fundamental and likely universal (or at least to a majority of our species). Frameworks may or may not work for some though the ones we find are likely those considered best practices already but take them with a grain of salt. Finally, you could use existing knowledge for guiding principles but do not forget that guiding principles is your own. Make it known to your circle to whoever you feel safe sharing it with. Refine them, share them and others might question them but it’s yours.

And if you lead a team, you share a part of your own guiding principles (its part of what we do is to sell that to our team) but help your team build it’s own as well. What you agree on, how to do things, what to do when things get tough and as important, what to do when things are great.

An analogy for software debugging/development might actually exist now that I think about it.
1- investigate the problem (why)
2- design and implement a solution (how)
3- create unit tests/automated tests and monitoring to help make sure it doesn’t happen again (what ifs)

So when faced with “where to start” this is what I do. Or at least what I think I do. At the very least this blog post is part of this process too.
1- I have a question which I think could benefit others and I’d love to share my thoughts on (why)
2- write and share on my blog (how)
3- I may not get feedback (I don’t expect anyone to read unless I point them here) or I get feedback (great – whether that’s good or bad) and I see if I could improve as I learn more – is my “what ifs”.

There will be guiding principles that will not be easy (e.g. do not lie – sounds simple but I don’t know if you can imagine how difficult that is with all the quirkiness/sensitivities of our modern world) but the good news is other than making it easy to make decisions at work, the side effect of these guiding principles maybe some peaceful goodnight’s sleep.

Keep learning, building and take it easy!

Categories
Career Growth Engineering Leadership

The 6 Different Leadership Styles You Need To Know About

Sharing an article written by the good folks at officevibe.com about leadership styles. The list could be endless, depending on who you ask and which book you read but I feel this captures them well enough for me to share. It’s a good reminder for those you might have had read too much books in the past and forgotten.

Leadership styles apply not just for work but even in the family, friends and politics. There are always debates on what works and doesn’t work which makes sense since every situation could be different. This does represent my own “default” though. And at the very least, knowing them will make us understand each other more and as they say, “if you only have a hammer everything is a nail”.

6 Leadership StylesThis infographic was crafted with love by Officevibe, the software that shows you how to be a good leader through employee feedback.

Categories
Career Growth Engineering Leadership Startup

My Quest to be a Better Leader

leadershipimage.jpeg
Leading Engineers

Engineering Leadership (or management – some engineers are not fans of the term “manager”) is not easy as some people think. Leadership is hard enough, the complexity of people then add to that the complexity of engineers. There’s not a lot of books on the specific subject so it’s not surprisingly that I still hear top executives saying that one just needs be technically proficient/architect, sure – architect of teams/people maybe but not just of systems/code. That’s where the challenges of engineering leadership comes in, one is expected to be both good at systems/engineering and people. Those two could mean different worlds.

Long topic but I wanted to share what I hope to follow and achieve. These are taken mostly from Google’s Proxy Oxygen (Google’s Quest for a Better Boss), books, articles I have read on the subject (you can catch some at my GoodReads account) and experience from peers, friends and my own.

These are “big” topics on their own, (obviously thousands of books have been written on leadership), my goal is to simply to share in case it helps and for others to remind me should I forget to walk the talk.

Also, though useful in most cases, it could vary depending on what stage your company/team is in. If you are just starting up, you need more coding + pitch/sales/marketing power more than maybe engineering leadership.

There is no timeline to get these right (if even possible at all), it’s a lifelong process and better have a target than nothing at all.

1. Be a good coach

  • Provide specific, constructive feedback, balancing the negative and the positive.
  • Have regular one-on-ones, presenting solutions to problems tailored to your employees’ specific strengths.
  • Learn more about coaching and apply (and be more organized, templates etc)

2. Empower your team and don’t micromanage

  • Balance giving freedom to your employees, while still being available for advice. Make “stretch” assignments to help the team tackle big problems.
  • Give them tools to enable them to do their best
  • Demand the very best, help if possible, otherwise find other options, if all is exhausted cut losses
  • Trust them to do their best
  • Emphasize results, not time spent
  • Delegate that which is not your strength

3. Express interest in team members’ success and personal well-being

  • Get to know your employees as people, with lives outside of work.
  • Make new members of your team feel welcome and help ease their transition
  • Treat them well
  • Know what makes them tick (money, power, status, popularity, greater good)
  • Appreciate individuality
  • Do the hard work of knowing but also ask what motivates them

4. Don’t be a sissy: Be productive and results-oriented

  • Focus on what employees want the team to achieve and how they can help achieve it.
  • Help the team prioritize work and use seniority to remove roadblocks.
  • Shield the team from distraction
  • Manage external expectations

5. Be a good communicator and listen to your team

  • Communication is two-way: you both listen and share information.
  • Understanding is the goal, communication is just a tool
  • Hold all-hands meetings and be straightforward about the messages and goals of the team. Help the team connect the dots.
  • Encourage open dialogue and listen to the issues and concerns of your employees.

6. Help your employees with career development 

  • Mentor when you can, refer to someone if outside your expertise
  • Training time on regular work week hours (internal + external expertise)

7. Have a clear vision and strategy for the team

  • Even in the midst of turmoil, keep the team focused on goals and strategy.
  • Involve the team in setting and evolving the team’s vision and making progress toward it.
  • Team vision, Core values
  • Where does each one fit in the team (roles)
  • To be the best, know the best (who are our competitors)
  • When saying no to roadmap/tasks, support it by giving costs

8. Have key technical skills so you can help advise the team

  • Roll up your sleeves and conduct work side by side with the team, when needed.
  • Understand the specific challenges of the work.
  • Learn their code base – invest time on this
  • Good architecture – “With good architecture, debugging is a breeze because bugs will be where they should be.” – David May
9. Integrity
  • Just, fair, transparent
  • Do not commit without consulting them
  • Admit mistakes
  • Give people proper credit
  • Confront problems, not people

10. Advocate Quality

  • Test, Test, Test
  • Code review
  • Simplify, Simplify
  • Continuous integration
  • Cannot commit if builds are failing
  • 5 whys – incident report always
  • Do not build something you cannot measure
  • Have a Devil’s advocate, 10th person on architecture decisions

11. Innovation

  • Advocate design thinking – emphatize, define, ideate, prototype, test
  • Safe environment to learn from instead of fear failures and move on